Episode 43: A good person by default

Episode 43: A good person by default:

thoughtbot’s Ben Orenstein is joined by Scott Orn, venture capitalist at Lighthouse Capital Partners by day, and co-founder of Ben’s Friends by night. Ben and Scott discuss building a community, the future of Ben’s Friends, and how running the site helps him be a better VC, teaching people, and getting value out of giving back. They also talk about his work as a venture capitalist at Lighthouse, how the money flows, the freemium software model, why it’s good and how it works, picking the winners, and how the market can affect success, and the companies Scott thinks are great investments, and where he thinks the market is going.

• Episode Notes and Links
• Subscribe via iTunes
• Subscribe via RSS
• Direct Download

Clojure: Expectations, Customize your Test Running Context

I've previously written about expectations' before run hook and the built in support for detecting state changes. These features are nice for reassigning vars you don't care about or detecting accidental state changes; however, there was no option for temporarily changing the context in which your tests are run. As of expectations 1.4.36, that's no longer true.

Version 1.4.36 allows you to alter the context in which your tests run by creating a function that takes the "run the tests" function as an arg, and do you as wish.

Too abstract, no problem, the code:

<script src="https://gist.github.com/jaycfields/5281648.js"></script>
That's it, if you add the previous function to your tests, you can define whatever you like in the in-context function, and your tests will be run in your custom context. The previous snippet is pulled from the expectations tests, which verify that success.success-examples-src/a-fn-to-be-rebound is correctly rebound. In the expectations tests an expectations_options.clj namespace is used to define in-context (expectations_options.clj explained here).

Why would you want to define your own context? In the past I've used in-context for two reasons: rebinding things I don't care about (e.g. calls to logging) to (constantly true), and rebinding things I never want called (e.g. create a new thread) to #(throw (RuntimeException. "not allowed in tests"))

I've been using in-context for about a month now, and it's worked well for me. Give it a shot and let me know how it's working for you.

Wrap existing text at 80 characters in vim

You have an existing block of text or code in vim. You want to re-format it to wrap to 80-characters.

:set textwidth=80

You might want this setting to apply automatically within certain file types like Markdown:

au BufRead,BufNewFile *.md setlocal textwidth=80

We have that setting in thoughtbot/dotfiles.

Select the lines of text you want to re-format:

v

Reformat it:

gq

Learn more:

:h gq

Using rbenv to manage rubies and gems

We recently switched from RVM to rbenv for managing Ruby versions.

“Make each program do one thing well.” - Precept #2 of The UNIX Philosophy

Why consider switching to rbenv?

The UNIX philosophy espouses an approach to software in which small, sharp tools are designed and used to address discrete needs. By this standard, RVM simply does too much. RVM is responsible not only for changing Ruby versions, but for installing rubies and managing gemsets, as well.

Breaking these responsibilities apart and selecting a tool for each job is a good alternative to using RVM. Along with rbenv, we’re using Bundler to manage gems (replacing gemsets) and ruby-build to install rubies.

How our rbenv workflow works

• Uses ruby-build to install Rubies
• Relies on Bundler and its’ binstubs to manage gems
• Uses shims to handle executable gems
• Updates shims upon receipt of the rbenv rehash command after new Ruby executables are installed (rehashing can be automated with the gem rehash plugin)
• Installs everything to ~/.rbenv/

How to switch from RVM to rbenv

Check out our laptop script to see our process for installing rbenv, or follow the steps below.

If you’re a tmux user, be sure to kill all your tmux sessions before installing rbenv to prevent RVM from polluting your environment.

In your root directory, remove RVM from your system:

rvm implode

Restart your shell to ensure you’re beginning your rbenv installation in a clean environment:

exec $SHELL -l

Next, install rbenv using homebrew:

brew update
brew install rbenv

Configure your bash or zsh profile:

echo 'eval "$(rbenv init -)"' >> ~/.zlogin
source ~/.zlogin

Install ruby-build and rbenv rehash gem using homebrew:

brew install rbenv-gem-rehash
brew install ruby-build

Install your preferred version of Ruby and set it as the global default:

rbenv install 1.9.3-p392
rbenv global 1.9.3-p392

Update to the latest Rubygems version:

gem update --system

Install gems critical to Rails development, e.g.

gem install bundler foreman pg rails thin --no-rdoc --no-ri

You can set project-specific Ruby and gem versions by running the rbenv local command within your project directory:

rbenv local 1.9.3-p385

If you follow the steps above and find you’re having issues with rbenv, check your echo $PATH. Most likely you’re not seeing the appropriate ~/.rbenv dir.

If so, you either haven’t added the init to your .zshrc, or something else is mangling the path.

Extras

• To ease the transition, install the use plugin, which lets you run RVM-style commands with rbenv
• rbenv-binstubs is a handy plugin that allows you to omit bundle exec when you run commands

Using GDB to inspect a running Ruby.

This job shouldn’t be taking this long!

Well, that’s not a great thing to have to say, is it? But I bet more than a few of you have said it before, and not many of you knew exactly why at the time. Oh, sure, with liberal use of puts and maybe pry you can figure out what a problem might be next time you run it, but sometimes you need to figure out what that problem is right now.

As it turns out, and I know this is a shocker, Ruby processes are just regular processes. They can be debugged with gdb.

Having recently had the need to find out why a job of mine was running particularly slowly, I found out about this lovely tool the hard way: frantic googling. I found some very useful functions for gdb in a blog post by Rasmus on Ruby callstacks.

define redirect_stdout
  call rb_eval_string("$_old_stdout, $stdout = $stdout, File.open('/tmp/ruby-debug.' + Process.pid.to_s, 'a'); $stdout.sync = true")
end

define ruby_eval
  call(rb_p(rb_eval_string_protect($arg0,(int*)0)))
end

How to use these:

1. Start up gdb by running gdb /path/to/ruby PID, where /path/to/ruby is the full path to the actual ruby binary and PID is the process ID of the ruby you want to check out.
2. Paste those functions above into the gdb prompt (you might also want to store them in ~/.gdbinit for later).
3. Run redirect_stdout, which will put all the ruby output into a file called /tmp/ruby-debug.PID where PID in this case if the process id of gdb — not terribly important, but a differentiator in case you do this a lot.
4. Run commands via ruby_eval('Kernel.caller') and object_id and things like that. You should be able to get local variables from wherever you broke into the program.

These ruby_eval commands will output into the tempfile that redirect_stdout created, so you’ll need to tail -f that file in a different console. Now, with that small headache over with, you can see exactly where your program is and if there is a stupid loop where you forgot to check a boundary condition, or what thing you’re doing with a regular expression on where you should have just used String#index.

(Incidentally, regular expressions aren’t usually the fastest means of string processing. Just so you know.)

Shoulda Matchers 2.0

Shoulda Matchers has been around for a long time. Unfortunately, it’s starting to suffer from feature bloat so we’re narrowing its focus to keep releases fast and the maintenance burden low.

Removing Deprecated Matchers

The following matchers were deprecated in 1.5 and will be removed in 2.0 . If you’re currently using these methods you should consider testing the code in another way.

assign_to

The assign_to matcher allows you to ensure you have set an instance variable properly. We do not use this because we typically cover those types of assertions implicitly through an integration test. An integration test may be slower than a unit test, but it provides more thorough coverage.

validate_format_of

The validate_format_of matcher allows you to perform the same operation as the allow_value matcher Please use the allow_value matcher instead.

should validate_format_of(:email).with('user@example.com')
should allow_value('user@example.com').for(:email )

have_sent_email

We recommend email-spec for testing emails in your apps. It has the added benefit of working with your integration suite as well as your unit tests.

respond_with_content_type

The respond_with_content_type matcher is not a matcher we use often. This behavior can be tested using the response object in your controller tests without the need for a matcher.

query_the_database

We do not have a recommended solution for a replacement on this matcher.

Matchers Removed Temporarily

The strong_parameters and delegate matchers will also be removed in 2.0. We ran into some trouble implementing them but hope to re-implement them in a less troublesome way soon.

New Hotness

As part of the move to 2.0, we will also be dropping support for Rails 2 & ruby 1.8. We will continue to support Rails 3.x and ruby 1.9.x and will be adding support for ruby 2.0 soon.

Keeping it tight

We are trying to keep Shoulda Matchers a tight focused gem and make sure the matchers we do support are as robust and thorough as possible. Do you think there are any other matchers we should remove?

Introducing The Playbook Online Workshop

We’ve been offering a video version of The Playbook for some time, and now we’re happy to announce the evolution of that concept, the new Playbook Workshop.

This workshop is the real-time, expanded version of The Playbook. We’ll start with the video lessons and then work together on practical examples and your own real ideas. We will go through an example of building an actual application and we’ll explore all of the pieces of the web design and development process, including the tools and team.

The first session of this new workshop runs from April 8th to the 19th, and is available for registration individually for $499, or you can subscribe to Learn Prime, to get access to this workshop, and all our other workshops, books, and screencasts for just $99/month.

Learn more and register today. I hope to see you in the workshop!

Being a Lead Consultant

These are not my ideas, they were given to me. I wanted to store them in a safe place, which is why they can be found here. Thank you for your wisdom Scott and Sean.

• Voice of authority to the client on technical matters, meaning that I'm looking for someone who can establish their own credibility with senior client staff, including non-technical managers. This means knowing what the client values and being able to communicate the important issues, not hung up on trivial issues.
• Leading developers by example. Other developers, particularly junior developers, will pick up and mimic behaviors of their lead developer in ways that may not even be obvious to either one of them. I look for the senior devs to understand this and model the behavior that want to see from their team.
• Understanding that it's not just about coding cards. This means making sure the relationship between the development team and the BAs and testers is fruitful and productive. Obviously, the PM and IM also have a role to play here but the senior developers are even more influential with other developers.
• Herding the technical team. This means being the guy to make sure the unfun cards get done, everyone responds to broken builds, and that there is a sense of signing up to and committing to work. A lot of this can come from the leadership by example but there is also a vocal component that I'm talking about here. Not being a cheerleader but willing and able to facilitate decision making in groups and address issues one-on-one as appropriate.
• Confidence-by-proxy. That is, your teams just feels safer/better/stronger when you're there, vs when you're not.
• Escalation conduit. Your team naturally pulls you into their trouble, or invites your contributions to their challenges/achievements
• Professional reflection. Your team is eager to hear your thoughts on their individual capabilities, reach.
• An interesting indicator is often the 'are they talking about what I think when I'm not there' test. That is, do they find themselves bringing your ideas/opinions/objectives into conversations, even when you're not present. Kind of a fun 'tell' of a powerful influencer/leader.