Developmentastic

  1. @lof Another option is acts_as_archive: http://github.com/winton/acts_as_archive

  2. @jnunemaker You should present at 10gen’s NoSQL conference on how @harmonyapp is utilizing MongoDB. http://10gen.com/events

  3. @pengwynn I did! A friend of mine, Nigel Soladu, sent me an internet letter offering me a business opportunity and I went with it.

  4. @pengwynn Unfortunately I just had to open a Bank of America account for the sole purpose of accepting international wire transfers.

  5. Fixing N+1 queries like it’s my job.

  6. @DDrDark Hi, person I’ve never met but have heard a lot about.

  7. @bylinebreak’s portfolio site running on @harmonyapp just went live: http://bylinebreak.com

  8. @jnunemaker Do you have any experience serving files from GridFS? Is it fast? Ready for production? Is S3 a better option?

  9. That’s a first. Previous dev wanted to call #link_to in a controller so he wrote a partial and called #render_to_string. Not a pretty sight.

  10. I must be doing something wrong. Here’s the code I came up with to stub file uploads to Cloud Files: http://gist.github.com/262919

  11. Doing work on a project rescue where the previous developer used AMQP to run slow, unindexed database queries in the background.

  12. Finally got around to uninstalling MacPorts and using Homebrew exclusively. A package manager using git and ruby seems too good to be true.

  13. My new toy: Using slime to execute cucumber features http://cld.ly/bfqxu

  14. Using Slime To Execute Cucumber Features

    I learned of the wonders of slime from David Whittington during his CPOSC talk on Clojure. He would write a line of code and, with a single keystroke, it would be whisked away and executed in a terminal window. This proved especially useful in his demonstration because he was able to write and manipulate blocks of code in vim and have it execute in the REPL. I tried it for myself when playing with Ruby and lisp to found it far more productive than monkeying around at the command line.

    You can get up and running with slime.vim in a few minutes. Jonathan Palardy wrote a detailed tutorial describing slime’s merits, his setup, and how to use it with irb. Absolutely worth a quick read.

    I’ve been meaning to find a decent solution to execute my tests from within vim instead of having to constantly switch between it and a terminal. I came across a post by Paul Battley outlining his solution using autocmd to define a few simple mappings any time a Ruby test file or Cucumber feature is opened. He’s updated the script since writing that post, so be sure to check out the living copy on GitHub. I spend a great deal of time writing Cucumber features so anything that makes executing them less painful gets my attention.

    I’m sure it’s obvious where I’m going with this. Using slime.vim, the opened feature or focused scenario can be sent to a terminal window to run in the background instead of running in the foreground of vim. Here’s what I ended up with:

    augroup Cucumber
  au!
  autocmd BufNewFile,BufReadPost,BufEnter *.feature,*.story
    \ set filetype=cucumber|
    \ :nmap <leader>r :call Send_to_Screen("cucumber -r features " . expand("%") . "\n")<CR>|
    \ :nmap <leader>R :call Send_to_Screen("cucumber -r features " . expand("%") . "\:<C-R>=line(".")<CR>\n")<CR>|
augroup END

    When editing the file features/account.feature, the mapping ,r (assuming comma is your leader) will send the command cucumber -r features features/account.feature to the screen session. ,R functions similar but appends the current line number so only the scenario your cursor is on will be executed.

    After using these mappings for a few minutes, I realized many times I’m inside a step definition or somewhere else outside of the feature and want to re-run the last scenario. A simple mapping to execute !! is all you need.

    :nmap <leader>l :call Send_to_Screen("!!\n")<CR>

    A sample workflow looks something like this:

    1. Setup a screen session as Paul describes.
    2. Open a feature and write a scenario.
    3. Mash ,R to run it.
    4. Tell slime.vim the names of your session and window.
    5. Watch it fail.
    6. Implement each step one-by-one and use ,l liberally to re-run the scenario.
    7. Commit.
    8. Rejoice.
    9. Repeat.

    Some things worth mentioning:

    • I tweaked slime.vim to default the session and window names to “s0” and “w0” respectively.
    • Only using screen a handful of times, it threw me off that it has its own scrollback. It makes sense, but I only run one session per terminal tab so I don’t mind disabling that feature.
    • It’s also nice to default the window title to the same value configured in slime.vim.

    Here are the relevant lines from my ~/.screenrc:

    termcapinfo xterm* ti@:te@
shelltitle 'w0'

    And an alias I threw into ~/.bashrc:

    alias s="screen -S s0"

    I’ll definitely be expanding these tools to better fit my workflow. If you have a clever addition or another approach to the problem, I’d love to see it.

    Update: I’ve been advised to clarify one point. slim.vim isn’t technically slime; it’s just a way to get some similar functionality in vim. Thanks, David, for pointing that out before the angry tweets started streaming in from emacs users.

  15. @rsoule You like 30 Seconds to Mars too?! I love the new Our Lady Peace - Spiritual Machines. It was so intriguing, I also bought the book.

  16. @alobodig I’ve been using @harvest for a few months now and love it. Great time tracking with their dashboard widget and simple invoicing.

  17. @daverobertson I love how you tweaked your avatar! Nice job.

  18. How does this work? The MP3 version of this album costs $0.50 MORE than a physical CD? http://cld.ly/40hwc Ridiculous.

  19. Tried writing a ci:build rake task, but couldn’t figure out how to run tasks in a different Rails environment with Rake::Task#invoke.

  20. Have to teach him the beauty of Ruby and TDD now before he’s lured to the dark side. http://bit.ly/qVIY6