Create a system that performs Steve Reich's composition "Clapping Music".
"Clapping Music" has two parts that are based on the same rhythmic cell.
Part 1 plays this rhythmic cell consistently throughout the piece (x means play a sound, _ means rest):
x x x _ x x _ x _ x x _
Part 2 begins by playing this cell then cycles through 11 variations, each of which is shifted by one beat.
I hereby claim:
To claim this, I am signing this object:
| function! ChangeUrls() | |
| args `cat .chapters` | |
| silent vimgrep /\Vhttp:\/\/\zsvimdoc.sourceforge.net\/htmldoc/g ## | |
| for hit in reverse(getqflist()) | |
| execute 'buffer' hit.bufnr | |
| silent call cursor(hit.lnum, hit.col) | |
| silent call MoveUrl() | |
| endfor | |
| endfunction |
Write a simple library to enable testing with spies.
Here's a simple ruby app which interacts with a database. The app has a passing test suite, but the tests are difficult to follow because they ask questions about return values. Refactor the tests so that they observe collaborators that have side-effects (rather than examining those side-effects).
I've written about one possible [workflow for doing project-wide search/replace in Vim][45].
This relies on a custom :Qargs command, which populates the arglist with each of the files listed in the quickfix list.
Having run that command, you can then run :argdo sub/find/replace/gc to substitute across all files in the argument list.
If only Vim provided a built-in :cdo command then this workflow would be more straightforward, and wouldn't require the custom :Qargs command.
Good news: Yegappan has implemented :cdo/:ldo/:cfdo/:lfdo commands. You can [read the discussion and find the patch][cdo-discussion] on the vim-dev mailing list.
Here are the steps that I used to download Vim source, apply the patch, and build Vim using the patched source code.
Create a tool for automating the steps required to build a javascript project.
A sample project is supplied with coffeescript files. These need to be compiled to javascript, then minified and concatenated. The build tool should be able accept generalised instructions for carrying out each of these steps.
Where possible the build tool should be lazy, only running steps if they produce fresh output.
The system will poll people for answers to yes/no questions that are easily answered by humans but not by machines. If a certain number of people give the same answer to a question, it's marked as resolved and polling for that question ceases. If people give different answers to the same question, then polling will continue until a consensus is reached and that question can be marked as resolved.
When someone has answered a question, they may view a summary of all answers to that question.
Here is [the Filco Majestouch 2 Tenkeyless Keyboard product listing][listing]. Tech specs:
Brand new, the keyboard sells for £114 (including VAT).
| command! -nargs=* Ember :echo system('ember <args>') |
| feature('foo bar', { | |
| given: function() { | |
| visit('/'); | |
| }, | |
| when: function() { | |
| fillIn('#some-field', 'foo'); | |
| click('button:contains("Submit")'); | |
| }, |