Google Hangout for Standups and Interviews

We’ve been experimenting with Google Hangout for meetings such as daily standups with remote team members and interviews with remote candidates.

We concluded this experiment was a success.

It’s nice to have a recurring calendar invite to open, click “Join Hangout” and start talking.

Google Hangout is sometimes choppy over wifi. The settings need to change when we switch from laptop to monitor, so we often are without sound for a few seconds before changing the “FaceTime Camera (Built-In)” setting to “FaceTime HD Camera (Display)”.

We’ve noticed in longer meetings, we sometimes need to refresh the page if sound starts to get choppy, presumably to clear some buffering.

We’ve noticed during Hangouts that the sound captured by a Macbook Air’s internal microphones is often muffled. We generally have Macbook Pros for better performance of test suites, but there are a few of us who have Airs. We have started to fall back to phone calls for sound in those cases.

Overall, it’s always better to see someone’s face.

Written by Dan Croak.

Ruby Science: You down with OCP?

Yeah, you know me.

We just pushed the latest update to Ruby Science, including five new chapters. Previous purchasers and Prime subscribers can grab the update on Learn.

New chapters this week discuss:

• Using the Single Responsibility Principle to create readable, reusable classes.
• Applying the Open/Closed Principle to reduce churn and prevent breakage while keeping objects easy to change.
• Applying the Dependency Inversion Principle to create flexible, reusable objects.
• Using the Law of Demeter to prevent application dependencies from becoming a tangled mess.
• Choosing Composition Over Inheritance to make simpler, more flexible software.

The book is a work in progress, and is currently 230 pages long. Your purchase gets you access to the current release of the book, all future updates, and the companion example application.

Get your copy of Ruby Science today.

Now Available For Free With Learn Prime

We recently launched a service to help subscribers become better developers, called Learn Prime.

For just $99/month, you get ongoing access to everything we teach, including books like Ruby Science. You’ll even get access to all our in-person and online workshops. Get access to exclusive subscriber content and use the forum to ask thoughtbot your toughest Ruby, Rails, and refactoring questions.

Subscribe now.

Written by Joe Ferris.

Reducing Churn in Subscription Services

You’ve probably heard by now that we’ve launched a learning community for passionate Rails developers called Prime.

Since Prime is a subscription service, one of metrics we’re interested in is churn, defined as the percentage of total customers who cancel. Over the last 30 days, Prime’s churn has been 18%.

Estimates of what a “good” churn is vary. One broad survey of SaaS companies with less than $10M in revenues showed a median churn of 20%, while some blog posts insist that anything over 8% should be panic-inducing.

To gain some perspective and get advice, I reached out to a friend and former podcast guest, Brennan Dunn.

Brennan is creator of a successful SaaS app called Planscope, author of several excellent ebooks, and overall “good at making money on the internet” kind of guy.

Below, you’ll find a recording of our 40-minute chat. In it, we dig into Prime’s current stats (including subscriber count and revenue growth), and Brennan’s suggestions for how to improve the site. What started off as recommendations for reducing churn turned into a broader discussion of how to position the entire service. If you run a subscription service of your own, you’ll likely learn a thing or two from Brennan’s battle-tested advice.

Check it out!

Direct download.

If our discussion left you with further questions for Brennan, leave them in the comments below and perhaps we can convince him to respond.

New screencast: Improving Performance for Real-time Requests

We’re pleased to announce our newest screencast video on Learn, Improving Performance for Real-time Requests.

This video, with thoughtbot CTO Joe Ferris, shows you how to tune performance using a real world example. Starting with an action that takes 3 seconds to respond and performs over 1600 database queries, Joe is able to reduce response time to 300ms and drop database usage to just 5 queries.

This video specifically focuses on what Joe calls ‘real-time requests’. That is, requests that must return all of their data to the user in the request-response cycle, without relying on background jobs or persistent caching.

Prime subscribers get this new video included with their monthly subscription. You can also purchase it individually for $15 or for your whole company for just $49.

Slow Rails applications annoy users and lead to lost revenue. Achieve a competitive advantage by making your application UNCOMFORTABLY FAST. Learn how today!