~/.tmux.conf:
bind z send-keys "say ack" C-m
~/.tmux.conf:
class Role < Module | |
IncompleteInterface = Class.new(RuntimeError) | |
def included(receiver) | |
missing_methods = @public_api.map(&:to_sym) - receiver.public_instance_methods.map(&:to_sym) | |
unless missing_methods.empty? | |
raise IncompleteInterface, | |
"#{receiver} must implement these methods: #{missing_methods.inspect}" | |
end |
Fluency is "what you can say without having to think about how to say | |
it." "Refactoring" is a language that describes ways to make your | |
code better. I want to inspire you to learn more of that language, so | |
you can make your code better without having to think about it. | |
I'll walk you through the process of reworking a 50-line controller | |
action that's hard to comprehend, let alone refactor. We'll tease | |
apart fiendishly intertwined code, embrace duplication, use dirty | |
tricks to our advantage, and uncover responsibilities that weren't | |
obvious when we started. |
class Brogrammer | |
def ponder_life | |
self.if(you == understand.this) { | |
get.a.girlfriend; | |
} | |
end | |
def if(predicate) | |
yield if predicate | |
end |
<?xml version="1.0" encoding="UTF-8"?> | |
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> | |
<plist version="1.0"> | |
<dict> | |
<key>AdjustWindowForFontSizeChange</key> | |
<true/> | |
<key>AllowClipboardAccess</key> | |
<false/> | |
<key>AnimateDimming</key> | |
<false/> |
Feature: Salary range comparisons | |
AS A person involved in a recruitment discussion | |
I WANT to know whether the candidate's and recruiter's expected salary ranges overlap | |
SO THAT I can avoid spending time on negotiations that can't ultimately be satisfied | |
AS A person who knows about the phenomenon of price anchoring | |
I WANT to approach this question without necessarily being first to name a number | |
SO THAT I don't compromise my negotiating position |
I mostly work in a wemux session so that my coworkers can SSH in and join me on | |
short notice, and have configured my tmux status bar to show the usernames of | |
everyone who's logged in. However, I also sometimes have tmux sessions open with | |
personal projects, and don't need to see usernames in *those* sessions. Also, | |
some people have really long usernames, so I want to assign them nicknames so | |
the entire list doesn't get truncated. |
[NOTE: The original version was posted in 2007 on an O'Reilly blog, but the page has been erroring out for months now. I'm copying it here because archive.org, while useful, can be slow. chromatic is a lovely person who (he thinks) probably has copyright to this piece.]
I propose the following convention: the actual lines of code that are directly related to the OFFS gem itself should be aligned with the left margin. Code inside the would_like_to
and may_still_need_to
blocks should be indented "normally", as though the surrounding OFFS do/end lines were not present. See the example Ruby file also in this gist.
This convention serves two purposes: