As a developer
I want to get better at making my PRs easier to review
So that they get reviewed sooner and I can merge faster => shorter cycle times
As a code reviewer
I want PRs that are easier to review
So that it's less work
module MT | |
def self.assert(desc, left, operator, right = nil) = puts (if msgs = self.send(operator, desc, left, right) then failure(msgs) else success(desc) end) | |
def self.test(desc, &block) ; puts desc ; yield ; puts "\n" end | |
def self.success(msg) = " \e[32m#{msg}\e[0m" | |
def self.failure(msgs) = " \e[31m#{msgs.join("\n ")}\e[0m" | |
end |
# Basic key operators to query the JSON objects : | |
# #> : Get the JSON object at that path (if you need to do something fancy) | |
# -> : Get the JSON object at that path (if you don't) | |
# ->> : Get the JSON object at that path as text | |
# {obj, n} : Get the nth item in that object | |
# https://www.postgresql.org/docs/9.4/functions-json.html#FUNCTIONS-JSONB-OP-TABLE | |
# Date | |
# date before today |
# 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 work across many computers (and even otherwise!), it's a good idea to keep a copy of your setup on the cloud, preferably in a git repository, and clone it on another machine when you need.
Thus, you should keep the .vim
directory along with your .vimrc
version-controlled.
But when you have plugins installed inside .vim/bundle
(if you use pathogen), or inside .vim/pack
(if you use Vim 8's packages), keeping a copy where you want to be able to update the plugins (individual git repositories), as well as your vim-configuration as a whole, requires you to use git submodules.
Initialize a git repository inside your .vim
directory, add everything (including the vimrc), commit and push to a GitHub/BitBucket/GitLab repository:
cd ~/.vim
Let's say the plugin is at a GitHub URL https://github.com/manasthakur/foo
.
First get the plugin by either cloning it (git clone https://github.com/manasthakur.foo.git
) or simply downloading it as a zip (from its GitHub page).
Adding a plugin in Vim is equivalent to adding the plugin's code properly into its runtimepath (includes the $HOME/.vim
directory by default).
For example, if the layout of a plugin foo
is as follows:
foo/autoload/foo.vim
foo/plugin/foo.vim
I highly suspect that the RSpec core team all use black backgrounds in their terminals because sometimes the colors aren’t so nice on my white terminal
I certainly use a black background. I'm not sure about the other RSpec core folks. Regardless, if there are some color changes we can make that would make output look good on a larger variety of backgrounds, we'll certainly consider that (do you have some suggested changes?). In the meantime, the colors are configurable, so you can change the colors to fit your preferences on your machine. First, create a file at
Backbone.Collection = { | |
fetch: function() { | |
var requestUrl; | |
if (isAFunction(this.url)) { | |
requestUrl = this.url(); | |
} else { | |
requestUrl = this.url; | |
} | |
--- HEROKU STEPS to SET UP: --- | |
(Make sure you're all pushed/pulled on master before doing anything heroku) | |
1. git init | |
2. git add -A | |
3. git commit -m “blah, blah” | |
4. heroku create | |
5. To add heroku ENV keys/variables → (If there are any). |