This method has a magic number:
def wait_time
@env[QUEUE_WAIT_HEADER].to_i / 1000
end
Let’s extract that to an intention-revealing name. We’ll type:
/1000<Enter> # Find the number we want to extract
cwmilliseconds_per_second<Esc> # Replace the number with a variable name
O<Ctrl+A> = <Esc>p # Assign the replaced number to the variable
The result:
def wait_time
milliseconds_per_second = 1000
@env[QUEUE_WAIT_HEADER].to_i / milliseconds_per_second
end
Under the covers:
<Ctrl+A> inserts the last text you typed in insert mode, so the variable name is available after replacing the numberAssuming your cursor is at the value you want to extract, this creates an intention revealing name in 10 keystrokes, plus the keystrokes it takes to type out the name.
Can you beat my Vim golf?
Need to display a date in your Rails app? First try:
Time.now.strftime "arrrround %H'ish"
To remove duplication, you imagine a time format initializer. Second try:
Time.now.to_s :pirate
Then you remember the :default localized key. Third time’s a charm:
l Time.now
It formats based on the config/locales/en.yml file:
en:
time:
formats:
default: "arrrround %H'ish"
date:
formats:
default: "arrrround %H'ish"
Dates work, too:
l Date.today
The same system lets you alter the display of “days ago” and “minute from now.”
We’ve noticed unpleasant trends in our most popular open source projects:
We believe the causes of the problems are:
We want to do better so we’re trying a new policy that we believe is helping.
The Github Issues queue should contain items we can act on and close quickly.
This means feature and help requests should be submitted to the appropriate mailing list. If you’re worried about your pull request not being accepted, reach out to us on the mailing list before you start coding.
We’re trying to keep issues restricted to two kinds:
We’re always going to be looking at pull requests before issues, meaning the fastest way to get your bug fixed is to submit a pull request that fixes it.
We’ve been doing this on a few projects and the results have been good.
By keeping the list restricted to items that we can act on quickly, we’ve brought Paperclip’s issues count down to 25 from hundreds and Factory Girl’s issue count has consistently been in the single digits.
Although this means that we’ll be closing some issues that might represent real bugs or valuable features, we’ve found that we can actually move more code through the queue by weeding out the issues that we can’t act on.
To recap:
I recently sat down with Mike Burns to discuss his operating system and computer setup. Mike uses an entirely Open Source stack.
We discussed how he got started with this, the current state of running Linux, as well as some of the unique benefits and cool features of doing so.
We decided to make this special video available for free, and you can watch it here.
We often discuss the principles we use to write what we consider good code - test-driven development, object-oriented programming, SOLID, DRY, Law of Demeter - the list goes on. Sometimes it’s useful to remind ourselves of the fundamentals.
Code makes an application work for users. Getting tests passing or removing duplication is useful, but the code needs to be shipped so that users can use it.
Code needs to work. Assuming that as a prerequisite…
When code is easy to understand, we can change or extend it faster and are less likely to make a mistake in the process. Readability counts.
When code is easy to change, we can iterate on user feedback faster.
When code is fun to work with, we’re happier. Building software is our full time job. If we go home every day feeling wrung dry, something is wrong with our process.
Yes. Following certain principles can result in shipping products faster with fewer bugs and more programmer happiness.
Test-driven development helps us understand code because we state the reason for each line of application code in the test. It also makes us happy by providing a clear process for working.
An automated test suite helps us change code because we have an early warning system when we break an existing component. It is fun to work with because we’re more confident and less fearful.
Removing duplication helps us read code by introducing semantic concepts and abstracting details. It also helps us change code by reducing the amount of code that needs to be touched for each change.
SOLID principles create individual components that help us understand code. SOLID helps us change code because components are reusable, swappable, and small.
Slow or brittle tests make code harder to change. We have to be careful about writing the correct tests and the correct amount of tests.
Code isn’t good when it’s tested, DRY, or SOLID. Code is good when it works and we can work with it. When our teammates can understand our code quickly, respond to change, and are relaxed and happy, we’re writing good code.