Introducing the Google Pay™ for Passes Gem

05 July 2020

At the Pittsburgh Cultural Trust, we decided to rollout mobile ticketing. Mobile ticketing is the process whereby customers can order, pay for, obtain and/or validate tickets using mobile phones, without the need of a physical ticket. After a lot of research, we landed on utilizing both Apple Wallet and Google Pay™.

My assumption going into the project was that the implementation of Google and Apple was going to be similar. Was I wrong! Google wants you to send them the data and they will generate and host the ticket for you. Apple takes the hands off approach of supplying the specification and relying on the application to generate and host the tickets. I was lucky that the passbook gem existed because it made the Apple implemention pretty straight forward.

As I turned to implementing Google Pay™ for Passes, I realized that there were not many developers who had done it before. The documentation was difficult to follow (links often linked back to the parent page), you needed a Google Merchant and Google Cloud account and troubleshooting with the logging was tedious. After successfully deploying the implementation for the Cultural Trust, I pondered extracting and opensourcing my work. As it turns out, open sourcing a project that would provide real value to the Ruby community has been a goal of mine.

Today, I’m introducing the Google Pay™ for Passes gem. After consulting with my friends on the Ruby Blend, the gem is paired with a demo application and I’ve included the VCR cassette tapes in the repository so developers can see the gem in action.

If you’re excited about the googlepay gem, please give the gem a star. If you’re extremely enthused, please give the gem a try and critique me on the documentation. No observation is too small. I’m looking forward to branching out to other pass types and into payments.

Note: The googlepay gem is not affiliated with or endorsed by Google.

Podcast Guest Hospitality

26 April 2020

The 5by5 Ruby on Rails podcast has been around since July 11, 2005. This is an impressive start date since it beats podcasts dominating the current media landscape by more than a decade. The host position has been through a few hands and I’m lucky to call myself the host for over sixty episodes. The podcast is backed by the 5by5 Network, the broadcast network for geeks, designers, developers, and entrepreneurs. They supply the publishing platform and advertiser connections. The content, publishing schedule, guest selection, editing, show note creation and intro/outro themes are entirely my responsibility.

As I’ve been stepping through the podcast recording setup with guests, I’ve started getting compliments for the experience my guests have had. As someone who consumes a lot of podcasts, I’ve borrowed some advice from many to tackle the question, “how would I want to be treated as a guest?”.

These are my tips for how I try to create the a positive experience for my guests, knowing that a lot are recording their first podcast.

Podcasting Tools


When I first approach a potential guest, I explain who I am, what the 5by5 Ruby on Rails podcast is (never assume) and why I think that they would be a great guest. I used to try to offer some recording times but I recently have switched to Calendly. It has been a game changer to choose ongoing recording slots in my schedule and to skip calculating timezones. I include podcast FAQs in my confirmation template.


I inherited Cast as the go-to tool for the Ruby on Rails podcast. Cast is a great online system for making and publishing high-quality podcasts. It’s a true one-stop shop. It offers recording, editing, mixing, hosting and publishing. Since 5by5 handles publishing, I utilize Cast for both recording and editing episodes. The Scheduler functionality will email both me and the guest 30 minutes prior to recording with a link to the studio.

Google Docs

Roughly a week before I record with a guest, I compile a list of questions that I intend on asking them. I will seek out their bio, include the sponsor read and the outro from the episode. I send the Google Doc over to the guest, with the ability for them to edit it to include a bio if I do not have one or to change the verbage on any of the questions. This has been my #1 tactic for encouraging new voices on to the show since I always promise to send my questions ahead of time.

Before the Podcast


Before I hit the Record button, I always check the guests’s audio for background noise and potential latency. I have them do the same for me. Audio quality has not always been a strong suit for me so I purchased a Blue Yeti USB Microphone to increase my sound quality.


  • The listeners are excited to hear from them! When I ask a question, I will always make sure the guest can offer a complete answer before I reply. It might lead to a slight pause to be edited out but this protects the guest from being interrupted. It can be hard to follow this rule; my guests make a lot of fascinating points.

  • I will often go on mute to adjust settings, make notations for the show notes, review the timing for a sponsor read or re-arrange questions for flow. Guests are welcome to mute during the intro and sponsor reads.

  • Editor for the win. If they are not happy with how they sounded on a response, I encourage them to take a brief pause and start over again. Believe me, I take the same luxury regularly. Don’t ever hesitate to interrupt the host with an audio or technical issue. It be the difference between a published or lost episode.

  • Always silence any electronics around you and keep your headphones in so my voice does not record on to their track. You only have to spend a few hours scrubbing your voice out before you carry that lesson with you forever. If you are recording with more than one guest (a rarity for me, but it happens), each guest should be at their own computer with their own microphone/headphone setup.

During the Podcast


How awkward is it when a podcast starts and the guest is put right on the spot with having to sell why they are there? I always read the guest’s biography at the top of the episode so I can weave in why I’m personally excited to speak with them. It puts the guest at ease because you are already two minutes into a live recording and they can ease into contributing.

First Question

My first question to my guest is always what their origin story is. It’s a great question because they can lie, be wrong or exaggerate the truth and we, the listening audience, would have no idea. If often leads to a few laughs and interesting callbacks I can turn to for the rest of the show.

After the Podcast

Wrapping Up

Once the show comes to a natural conclusion, after I ask them for their take on our community and how listeners can follow them, I thank them on the recording for their appearance.

Follow Up

After the recording has halted but I’m still on the line with guest, I thank them again and bring up a highlight from the show. Consulting my show notes, I check to see if I need them to send me any followup links. If I have everything, I give them an intended publish date, promising them an email and a tweet when the episode is live.

Treating my guests well is a top priority for me as a podcast host. This process has gone through many iterations and I expect it to continue to evolve. If you have additional tips for me, please reach out or tweet to me. Of course, you can catch new episodes of the 5by5 Ruby on Rails podcast here.

Many thanks to the support I receive from the 5by5 Network and the hosts that have come before me.

Contextual Camouflage

03 August 2018

Contextual Camouflage is an open-source gallery art installation built in Ruby on Rails that guides visitors to anonymously report mental health disorders that affect themselves or their relationships. After users submit a disorder, they have the option to include anecdotes and demographic data for intervention researchers.

The application was born out of Steelcity Codefest in 2017. After the hackathon was over, we pared down the team and restarted the application with a smaller team of three: me, Danielle Greaves, and Jeff Waltrowski. We continued to work with Jason McCoy, head of McCoy Creative, the mastermind and designer of the concept.

We pitched the idea of hosting an installation in the Cultural District to my employer, the Cultural Trust. They had a new space they were prepping for future installations and they generously offered it to us for our trial run. With Railsconf coming to town the week of April 17th - 19th (I was scheduled to present on it), we launched the installation on April 15th, 2017. The installation completed during the Trust’s Spring 2018 Crawl.

Event Description

Contextual Camouflage sheds light on mental health issues and brings those living with mental health issues out in the open, showing that they’re not alone, and that mental health issues are more prevalent than some assume. By allowing visitors to namelessly submit their experiences with mental health and tell their story, gathering all of that data and plotting a heat map of experiences in a real-time display. During the Crawl, a selection of Storytellers will share their experiences and tell the world how mental health has affected their life, relationships, and community.

The pride I felt as our talent Storytellers bared their souls in front of the installation was undefinable. Through the night, I had a lot of hearltfelt, honest conversations about mental health.

We have plans to continue to build out the project and to host the installation in more locations. If you are interesting in contributing or collaborating, please contact me.



With help from “amazing code ninjas,” Contextual Camouflage exhibit explores mental health

90.5 WESA Interview with Jason McCoy


How to Add a Slack Notifier with Slack-Notifer and Sidekiq

13 April 2017

Recently, my boss had the brilliant idea to route the request to a private Slack channel when our Ruby on Rails website processed a customer’s contact form. It’s ideal for spotting specific website issues and to stay tuned to our patrons interacting with our site.

I came across the excellent slack-notifier gem. I bundled in:

gem "slack-notifier"
gem "json"

Time to add in a custom incoming webhook in Slack. Incoming Webhooks are a simple way to post messages from external sources into Slack. They make use of normal HTTP requests with a JSON payload that includes the message text and some options. Once you have the Slack URL, I added it to our Figaro application.yml as SLACK.

Next step is to add an initializer for Slack in config/initializers/slack.rb.

require 'slack-notifier'


We’re already proud Sidekiq users. Processing the Slack message was ideal for a background worker so let’s build a SlackNotifierWorker.

require 'json'

class SlackNotifierWorker
  include Sidekiq::Worker
  queue_name = "default"
  sidekiq_options queue: queue_name

  def perform(hash={})
    notification = {
        "username": "csibot",
        "icon_emoji": ":loudspeaker:",
        "fields": [
                "title": "Organization",
                "value": "#{hash['org']}"
                "title": "Path",
                "value": "#{hash['site_id']}"
                "title": "Category",
                "value": "#{hash['category']}"
                "title": "Notes",
                "value": "#{(hash['notes'])}"
    } notification


Remember to set the queue (default since it is not critical), emoji icon (important!) and to utilize Slack’s nifty message formatter.

Our last step is to trigger the SlackNotifierWorker during the flow of a user submitting a contact form.

SlackNotifierWorker.perform_async(org: @org, notes: @notes, category: category_string, site_id:

That’s everything. Special thanks to Steven Sloan and Mike Perham for making this so easy to implement.

How to Deploy Rails with AWS CodeDeploy

16 March 2016

Now that I’m working at a large non-profit, I’m getting to stretch my DevOps skills a bit farther (with the help of our awesome Ops team). As we’re moving our Rails app from version 2 to 4, it was time to see if we could retire the legacy application that we maintained to deploy the old app to production.

Since we’re big users of AWS, my team was excited to learn about their relatively new service: AWS CodeDeploy. CodeDeploy is a free AWS service that efficiently deploys your released code to a “fleet” of EC2 instances while taking care to leave as much of the fleet online as possible. Ship it!

I hunted around AWS’s documentation and GitHub for any examples of deploying with Rails but came up empty handed. After a few (OK, many) failed deployments, we came up with a solid workflow.

Here is what we did:

  1. Setup an EC2 instance with everything that you need for your production server. In our case, this was Ruby, Passenger, and nginx. You do not want to clone your app via git to the server ahead of time but you will need to know the path of where you want your app to live on the server (for example www/var/…). Make sure you know which users you will use for each process (cloning the code, restarting the processes).
  2. Install the AWS CodeDeploy agent on to the server.
  3. Move the EC2 instance to a Production App Group AMI.
  4. In our codebase, we added the following bash scripts to our /script folder. Our full scripts are a bit more complicated (cloning our env vars from a secure s3 bucket) but these will get you off to a solid start. CodeDeploy currently hooks into GitHub only. Luckily, GitHub is what we are using to manage our codebases.
  5. Setup a required AWS CodeDeploy appspec.yml at the root of your app that references these scripts (see below).


version: 0.0
os: linux
  - source: /
  - object:
    - location: script/
    - location: script/


cd /var/www/
RAILS_ENV=production bundle install --path vendor/bundle
RAILS_ENV=production bundle exec rake db:migrate
RAILS_ENV=production bundle exec rake assets:clobber
RAILS_ENV=production bundle exec rake assets:precompile


sudo service nginx restart

Commit these changes and make note of the commit ID. Next, it’s time to set up CodeDeploy. From here, AWS has it covered in their walkthrough. Wash, rinse and repeat for your Staging setup.

After you have CodeDeploy setup, you will be simply need to know the commit ID, the group you want to deploy to and the frequency that you want your servers deployed in (one at a time, all together or half at a time). CodeDeploy does integrate with our CI service, TravisCI, but we have not setup the integration yet.

CodeDeploy will render a success or a failed message after your deployment completes. If it does fail, CodeDeploy links you to the relevant logs so you can troubleshoot the issue.

AWS CloudTrail automatically logs all of the deployment requests so you have a running log of who and what was deployed. Granted, CodeDeploy still feels new (they update the UI constantly) but I feel confident that the free service will only get better.

I hope more teams will start adopting CodeDeploy once they realize it is free, stable and a great way to shed homegrown tools for deployments.

Thanks to the Pittsburgh Cultural Trust for giving me a great environment to learn awesome tools like these.

The Joys and Challenges of Hiring Developer Bootcamp Grads

16 January 2016

I was recently asked to speak on a Winning the Talent War: Building a Diverse Community of Junior Developers & Technical Talent panel in Pittsburgh. The idea was to gather HR executives to listen to tech talks and a panel discussion around solving Pittsburgh’s small tech talent pool. Sadly, the event was canceled.

Since I had completed my talk outline already, I figured that I would recycle it into a blog post for you, lucky reader. I’ll even reveal my biography from the event page:

Brittany Martin is the Lead Ruby Developer for the Pittsburgh Cultural Trust and a Rails Mentor for She is focused on bringing more women into tech and finding a way to cast her chocolate lab as Alf’s stand-in for the inevitable Netflix reboot.

Sounds like me, right? Away with the talk….

Makeup of a Typical Bootcamp Student

You = refers to the intended audience, HR executives in Pittsburgh

As a Ruby mentor for Bloc, I interact with a lot of potential junior developers. It’s amazes me how diverse their intentions are. If I focus on my students who are looking to make a career change, they share these characteristics:

  1. They have already had successful careers. They are looking for a new challenge that may lead them to a job with more flexibility, compensation and innovation. They have not flunked out of one career and are looking to sneak their way into another.
  2. They are smart. They have tried coding and instantly liked it. They understand that learning to code can be one of the most frustrating challenges that they will ever face.
  3. They are willing to invest in their future. These are employees that are willing to spend all their free time to acquire new skills.

The Pittsburgh tech community hasn’t seriously considered hiring bootcamp graduates even though they constantly struggle with hiring technical talent. Bootcamp graduates (BGs for short) can solve a lot of hiring needs, as long as the challenges they bring are addressed.

Joys of Hiring Bootcamp Graduates

Stale company culture? Hiring BGs can breathe new life into the workplace. They typically set a great example with their passion and high work ethic. Since BGs are encouraged to engage in the Meetup circuit while learning to code, they can often refer a lot of new candidates and get your company involved in your local community.

As noted, BGs have a past life that should be accounted for. They can bring a lot of domain expertise to their new jobs. I love seeing ex-nurses working at a healthcare startup, ex-CPAs working at a financial services company or ex-product managers assisting with project management at their new company. Make sure that when you interview BGs, you get their entire history, not just their coding timeline.

By training a new technical employee, a lot of bad processes can be revealed. BGs will quickly point out poor documentation, bad on-boarding steps and flimsy feedback loops. Remember, these students put their entire livelihood on the line to switch careers. They are heavily invested in making their new job work.

Challenges of Hiring Bootcamp Graduates

Setting up your company to interview and nurture bootcamp graduates is no small feat.

Unfortunately, a lot of bootcamp graduates are not taught basic project management skills and how to collaborate with an engineering team. When they are sole developers coding CRUD apps, they can get away with ad-libbing features. Learning how to properly submit pull requests, spec and estimate features and to balance work and life are skills that will need to be added to on-boarding. Getting BGs in front of real customers and prospects is important. Prior, it’s a smart idea to coach them to not promise features, to not guide the customers into answers and to listen for why they are asking for x feature.

BGs will need to be given plenty of room to fail. This will feel uncomfortable for you and for your organization. Working with your product managers to allocate extra time on earlier projects will pay off. Otherwise, BGs will deviate to doing safe tasks so they won’t grow as developers. In an ideal world, you will be able to hire BGs two or three at a time. Of course, this comes down to budget and bandwidth. It’s important that they can lean on each other and use each other as a health check. Just remember that if you have an 8 person engineering team and you hire 2 BGs, they will instantly make up 20% of your culture. Try to instill good habits early.

Hiring BGs in sets will also reduce the strain on senior mentorship. BGs are used to having mentors available to them so that they can feel good about the technical decisions they make. It’s important that you evaluate your engineering team prior to hiring to be sure your engineers want to mentor. Nothing is worse than see a mentor/mentee relationship fall apart because the mentor doesn’t want to teach or ignores feedback.

The Fictional Developer Wand

13 September 2015

3 years ago, I was a non-technical Product Manager and now I am a Web Developer.Not a week goes by where I don’t receive emails from potential developers asking for help. While some of these hopefuls understand the incredible time and energy it takes, it continues to amaze me how many assume I found and have a magic wand to gift them. With a simple wave, they will be transported from a job they hate into a fabulous world where they are sought after, well paid and will never have another worry again.

If you’ve gone through the intense process of learning how to code, you know this wand doesn’t exist. As a mentor and graduate of, I believe my learning was greatly accelerated by having a dedicated mentor and a structured curriculum. It’s glamorous to think that I worked full-time, completed my Bloc course and was instantly hired into a developer job that I wanted to keep forever.

What is my responsibility to reveal, my sprezzatura, is that I had a coding background. I had taken computer science courses in high school (only girl!), excelled in several coding classes at CCAC, barreled through some Coursera Python courses and even tutored Java for a year. To me, zero (never opened a text editor) to hired (12 weeks later getting paid $80k+) is just not feasible.

If you are looking to switch into a developer career, focus on the second job. I look back on my job at Ninefold fondly. I’m grateful that they gave me a chance when I hadn’t held a technical position before. I was not a Junior Developer but a Support Engineer. Day to day, I helped experienced developers deploy their production apps on to our PaaS. The amount of learning that came from that job was incredible. I was paid to troubleshoot coding issues when most of the times, StackOverflow was open next to my chat window.

Your dream job is likely two career moves away rather than one. This moment in time, right now, I truly believe I have made the switch from non-technical to technical. I proved myself at Ninefold and was asked to join NIRD when Ninefold pivoted out of the U.S. (shoutout to the wonderful NIRD team for believing in me) and recently joined the Pittsburgh Cultural Trust as their backend developer. While my first technical job was memorable, it was not the role that I had in mind when I graduated from Bloc. I want more potential developers to walk away from this understanding that it takes a lot of work to learn how to code and to keep that second job in mind.

When I hear complaints that there are not enough Junior Developers roles to keep up with all of the bootcamp graduates, I think to myself how many great roles are out there: technical project managers, IT, DBAs that could be filled by a Junior Developer. Junior Developers that are creative and diligent in continuous learning will be the ones to score that second dream job.

I’d love anyone’s thoughts on this especially if you have completed a dev bootcamp or are looking to make a career switch. A big thank you to Joe Esposito for editing and contributing ideas to this post.


Pittsburgh, PA USA