If you are like many (most?) of us, you have encountered Rails
Credentials/Secrets and secret_key_base and may have been
left a bit (or more) confused.
This post is an attempt to remove some of that confusion by
| # official docs: https://graphql-ruby.org/dataloader/sources.html | |
| # app/graphql/sources/association.rb | |
| class Sources::Association < ::GraphQL::Dataloader::Source | |
| def initialize(association_name, scope = nil) | |
| @association_name = association_name | |
| @scope = scope | |
| end | |
| def fetch(records) |
| # The following comments fill some of the gaps in Solargraph's understanding of | |
| # Rails apps. Since they're all in YARD, they get mapped in Solargraph but | |
| # ignored at runtime. | |
| # | |
| # You can put this file anywhere in the project, as long as it gets included in | |
| # the workspace maps. It's recommended that you keep it in a standalone file | |
| # instead of pasting it into an existing one. | |
| # | |
| # @!parse | |
| # class ActionController::Base |
If you're hacking on your Gemfile and using Docker, you know the pain of having the bundle install command run after you've added or removed a gem. Using docker-compose you could mount a volume and stage your gems there, but this adds additional complexity and doesn't always really solve the problem.
Enter this imperfect solution:
What if we installed every gem into it's own Docker layer which would be happily cached for us?
gem-inject-docker does just that. It takes the list of gems used by your app via bundle list and transforms it into a list of RUN gem install <your gem> -v <gem version> statements and injects them into the Dockerfile at a point of your choosing.
| <snippet> | |
| <content><![CDATA[ | |
| <template> | |
| ${0} | |
| </template> | |
| <script> | |
| export default { | |
| props: [${1}], | |
| data() { |
Since Golang version 1.11 this process is finally (almost) as easy as it should (!!). You can see full docs here. For older guides see here.
These are my notes, not a generic solution. They are not meant to work anywhere outside my machines. Update version numbers to whatever are the current ones while you do this.
Last updated March 13, 2024
This Gist explains how to sign commits using gpg in a step-by-step fashion. Previously, krypt.co was heavily mentioned, but I've only recently learned they were acquired by Akamai and no longer update their previous free products. Those mentions have been removed.
Additionally, 1Password now supports signing Git commits with SSH keys and makes it pretty easy-plus you can easily configure Git Tower to use it for both signing and ssh.
For using a GUI-based GIT tool such as Tower or Github Desktop, follow the steps here for signing your commits with GPG.
| # migrating from https://github.com/robbyrussell/oh-my-zsh/blob/master/plugins/git/git.plugin.zsh | |
| # Aliases | |
| alias g='git' | |
| #compdef g=git | |
| alias gst='git status' | |
| #compdef _git gst=git-status | |
| alias gd='git diff' | |
| #compdef _git gd=git-diff | |
| alias gdc='git diff --cached' |