giant robots smashing into other giant robots

How to write a great README

Sun, 19 May 2013 17:27:00 -0400

Leadership is often defined as having the ability to make others want to do what it is that you would like them to do. You want people to want to use your software, and often their first introduction will be through the README in the source code or on the project’s GitHub page.

The Basics

There are of course components to a technical document that make it more effective. Describe what it is that your project makes easier. Provide code examples detailing how the use of the library. Document the installation process. These are the basic elements which define a README.

Creating a great face for your project, however, requires still more.

Don’t get lazy just because this is for developers

Technical writing is still writing, and need not be dry and boring. Just as if you were writing an essay or blog post, you should strive to grab the attention of your reader early. This can be easily accomplished with a well-written introductory paragraph. Use strong or emphasised text to give a short description of what the software does, such as “Receive emails in your Rails app”. You can also use an image which relates to the functionality of your library or alludes to some pun in the name.

Your readers will most likey view your README in a browser. Please keep that in mind when formatting its content. Put the name of the library in an <h1> at the beginning of the file. Categorize content using two or three levels of header beneath. Make use of emphasis to call out important words. Link to project pages for related libraries you mention. Link to Wikipedia, Wiktionary, even Urban Dictionary definitions for words of which a reader may not be familiar. Make amusing cultural references. Add links to related projects or services.

The code matters

Besides speaking English, your readers also understand code. Developers love to see code samples, and a few lines of syntax highlighted source are worth a thousand words. plataformatec/simple_form does an excellent job of providing code examples as well as explanations for nearly every setting and interface call. Besides being extremely greppable, simple_form’s README is the top Google hit for nearly all simple_form searches.

Be aware that sometimes the reason someone is visiting your project’s page is that they have a problem. If you know about persistent issues, such as resolving a functional dependency, call that out in a section of its own and provide a solution or workaround. Right in the README. Yeah. A great example of one such issue is thoughtbot/capybara-webkit’s dependency upon Qt. Because a gem cannot satisfy this dependency, we added a notice about installation issues to the README.

You are also encouraged to add “badges,” such as Travis CI’s or Code Climate’s to your README, but remember that they reflect on your project—a passing build with high quality code attracts developers to your library, while a failing master build can give them pause.

Written by Caleb Thompson.

Sandi Metz’ rules for developers

Fri, 17 May 2013 11:30:00 -0400

Back in January, Sandi Metz introduced her rules for developers in a Ruby Rogues podcast episode episode. Around the time Sandi’s rules were published, the team I am on was starting a new project. This post details the experience of that team applying Sandi’s rules to the new application.

The rules

There are four rules.

Here are the rules:

Classes can be no longer than one hundred lines of code.
Methods can be no longer than five lines of code.
Pass no more than four parameters into a method. Hash options are parameters.
Controllers can instantiate only one object. Therefore, views can only know about one instance variable and views should only send messages to that object (@object.collaborator.value is not allowed).

When to break these rules

Paraphrasing Sandi, “You should break these rules only if you have a good reason or your pair lets you.” Your pair or the person reviewing your code are the people who you should ask.

Think of this as rule zero. It is immutable.

100-line classes

Despite the large number of private methods we wrote, keeping classes short proved easy. It forced us consider what the single responsibility of our class was, and what should be extracted.

This applied to specs as well. In one case, we found a spec file ran over the limit which helped us realize we were testing too many features. We split the file into a few, more focused, feature specs.

That made us realize that git diffs wouldn’t necessarily show us when we exceed 100 lines.

Five lines per method

Limiting methods to five lines per method is the most interesting rule.

We agreed if, else, and end are all lines. In an if block with two branches, each branch could only be one line.

For example:

def validate_actor
  if actor_type == 'Group'
    user_must_belong_to_group
  elsif actor_type == 'User'
    user_must_be_the_same_as_actor
  end
end

Five lines ensured that we never use else with elsif.

Having only one line per branch urged us to use well-named private methods to get work done. Private methods are great documentation. They need very clear names, which forced us to think about the content of the code we were extracting.

Four method arguments

The four method arguments rule was particularly challenging in Rails, and particularly in the views.

View helpers such as link_to or form_for can end up requiring many parameters to work correctly. While we put some effort into not passing too many arguments, we fell back to Rule 0 and left the parameters if we couldn’t find a better way to do it.

Only instantiate one object in the controller

This rule raised the most eyebrows before we started the experiment. Often, we needed more than one type of thing on a page. For example, a homepage needed both an activity feed and a notification counter.

We solved this using the Facade Pattern. It looked like this:

app/facades/dashboard.rb:

class Dashboard
  def initialize(user)
    @user = user
  end

  def new_status
    @new_status ||= Status.new
  end

  def statuses
    Status.for(user)
  end

  def notifications
    @notifications ||= user.notifications
  end

  private

  attr_reader :user
end

app/controllers/dashboards_controller.rb:

class DashboardsController < ApplicationController
  before_filter :authorize

  def show
    @dashboard = Dashboard.new(current_user)
  end
end

app/views/dashboards/show.html.erb:

<%= render 'profile' %>
<%= render 'groups', groups: @dashboard.group %>

<%= render 'statuses/form', status: @dashboard.new_status %>
<%= render 'statuses', statuses: @dashboard.statuses %>

The Dashboard class provided a common interface for locating the user’s collaborator objects and we passed the dashboard’s state to view partials.

We didn’t count instance variables in controller memoizations toward the limit. We used a convention of prefixing unused variables with an underscore to make it clear what is meant to be used in a view:

def calculate
  @_result_of_expensive_calculation ||= SuperCalculator.get_started(thing)
end

Great success!

We recently concluded our experiment as a success, published results in our research newsletter, and have incorporated the rules into our best practices guide.

Written by Caleb Thompson.

Google Hangout for Standups and Interviews

Tue, 14 May 2013 09:30:15 -0400

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.

Episode 48: Barista imposter syndrome

Mon, 13 May 2013 10:00:02 -0400

Episode 48: Barista imposter syndrome:

In this episode, recorded at RailsConf 2013, Ben Orenstein is joined by Jon Larkowski, closet hippie and developer at CareZone. Ben and Jon discuss being a closet hippie, transitioning from consulting to working on a startup/product team, ping-pong, paying attention to your habits and improving to your life, meditation, firewalling your attention, fostering a startup culture, imposter syndrome, podcasting, coffee, code review, guitar, and much more.

Ruby Science: You down with OCP?

Fri, 10 May 2013 13:24:00 -0400

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

Fri, 10 May 2013 09:30:29 -0400

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

Thu, 09 May 2013 14:12:16 -0400

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!

Announcing Learn for iPad

Wed, 08 May 2013 19:30:00 -0400

Today we released a new version of Learn to the App Store, which adds the most frequently requested feature, iPad support!

Additionally, this release includes several improvements on both iPhone and iPad. Resources that are available as iBooks can now be viewed in the iBookstore, better navigation controls have been added to web resources, and check-offs are now accompanied by sweet audio feedback.

If you would like to add resources to the Trail Map that the app uses, please contribute to the open source repository on GitHub.

Learn is available for free on the App Store, so try it out today!

Written by Diana Zmuda.

Episode 47: Two hours per minute

Mon, 06 May 2013 10:00:19 -0400

Episode 47: Two hours per minute:

In this episode, recorded at RailsConf 2013, Ben Orenstein is joined by Ryan Bates of RailsCasts. Ben and Ryan discuss Ryan’s transition to working on RailsCasts full time, staying up to date on the latest technology, how his coding style has changed, maintaining his open source, the process of producing RailsCasts, why he doesn’t speak at conferences, the latest technology he is excited about, and much more

Strong parameters as documentation

Wed, 01 May 2013 14:56:00 -0400

Besides moving attribute whitelisting to the controller rather than the model, Rails 4’s move to Strong Parameters over attr_accessible provides great documentation about the data with which records are being created.

strong_parameters are good and you should feel good

Here is an example of a controller many of us have written, using strong_parameters:

class CommentsController &lt; ApplicationController
  respond_to :html

  def create
    @comment = Comment.create(comment_params)
    respond_with @comment
  end

  private

  def comment_params
    params.
      require(:comment).
      permit(:body).
      merge(user: current_user, commentable: commentable)
  end

  def commentable
    # find and return a commentable record
  end
end

Notice how the comment_params method tells you at a glance what object’s parameters this controller/action cares about (comment), the specific data being used (body), and the extra information being added. After glancing at the method, you hardly have to concern yourself with the rest of the class: everything just makes sense.

strong_parameters will be standard in Rails 4.0, but they can be used now in Rails 3.*.

Written by Caleb Thompson.

We're at RailsConf 2013!

Tue, 30 Apr 2013 01:19:00 -0400

Winter is finally over, spring is here, and thoughtbot folks have flown in from Boston, San Francisco, Stockholm, and Boulder to be at RailsConf 2013!

Do you have any questions about our open source projects? Do you need some help setting up your project on Trajectory, or do you want to Learn something? We would love to chat with you!

We’re also setting up a temporary studio for our podcast in room D136. Feel free to stop by to say hi and watch us record live!

Adarsh Pandit, Ben Orenstein, George Brocklehurst, Harlow Ward, and Prem Sichanugrist are giving talks:

Tuesday at 11:30am: TDD Workshop: Outward-in Development, Unit Tests, and Fixture Data
Tuesday at 12:20pm: TDD Workshop: Mocking, Stubbing, and Faking External Services with Harlow Ward and Adarsh Pandit:

thoughtbot are creators of the open-sourced testing tools FactoryGirl and Shoulda Matchers.

We recognize Test-Driven Development (TDD) can be difficult to practice as features increase in complexity. Testing is often skipped when developers feel uncomfortable with TDD or have not yet seen certain approaches in practice.

We’ll describe specific techniques used in TDD which touch on: Integration testing with RSpec+Capybara, Model Associations and Data Validations, Asynchronous Jobs, Emails, 3rd Party Services, and JSON API endpoints.

Tuesday at 2:00pm: Sleeping with the enemy with George Brocklehurst:

In this session we’ll go off the Rails and take a look at what our Pythonista cousins are doing with Django.

I’ll start with some live coding: recreating DHH’s infamous 15 minute blog demo using Django and explaining the building blocks of a Django app along the way. I’ll then take that app and use it to look at some design decisions Django makes, and how they compare to Rails. You’ll see convention over configuration in places you didn’t expect it, why Django doesn’t need attr_accessible or strong parameters, and how the template method pattern could change your life.

Why talk about Python at a Rails conference? Seeing another way of doing things forces us to think about what we’re doing, challenges or validates the assumptions we make about our work, and inspires us to try new things.

Wednesday at 2:00pm: Zero-downtime payment platforms with Prem Sichanugrist and Ryan Twomey (from LevelUp):

When you’re building a payment platform, you want to make sure that your system is always available to accept orders. However, the complexity of the platform introduces the potential for it to go down when any one of the moving parts fails. In this talk, I will show you the approaches that we’ve taken and the risks that we have to take to ensure that our platform will always be available for our customers. Even if you’re not building a payment platform, these approaches can be applied to ensure a high availability for your platform or service as well.

Thursday at 10:30am: How to Talk to Developers with Ben Orenstein:

Nearly every developer will be asked to present to his or her peers at some point. Those that do it well will tend to have an outsized influence on their team, company, and community.

This talk will demonstrate (mostly by example) the straightforward techniques for giving excellent presentations, from a veteran conference speaker and teacher. Topics to cover include:

Phrases that turn your audience against you.

Basic body language tips that affect perception.

How to be more interesting than the internet.

The power of live coding and demos.

Being funny without resorting to reddit memes.

How to get plenty of questions during Q&A.

How to get an unfair amount of talk acceptances (aka ‘Bribing conference organizers’).

Episode 46: We don't have a monopoly on being unhealthy

Mon, 29 Apr 2013 10:00:30 -0400

Episode 46: We don't have a monopoly on being unhealthy:

Ben Orenstein is joined by Joe Kutner, programmer and author of ‘The Healthy Programmer’. Ben and Joe discuss how the demands of a development job lead to unhealthy habits, and ways to address the issues. They discuss specifics like standing desks, walking desks, the pomodoro technique, exercise, vitamin D, and much more.

It's for the orphans!

Sat, 27 Apr 2013 09:30:00 -0400

Too often, I come across GitHub Pages branches (gh-pages) branches that are simply forks from the master branch of the repository. This is not ideal.

There are several problems with this strategy:

Unless you manually update the gh-pages branch every time you add a commit to master, you will be out of date.
It makes for a much more difficult to understand source folder for the jekyll or HTML site, since people have to mentally categorize every file and folder into either “part of the site” or “an artifact from the master branch”.
It introduces the need to have lines like this in _config.yml to prevent unrelated files from being included in the gh-pages site:

exclude: ./app, ./lib, ./project.gemspec, ./Gemfile, ./LICENSE, ./Rakefile, ./readme.md, ./features, ./spec

`git checkout --orphan gh-pages`

When it comes time to create a GitHub Page for your project, use the above command. This creates a branch that is completely separate from the history of the rest of the repository. You will need to delete the files by running “git rm -rf .”:

If you want to start a disconnected history that records a set of paths
that is totally different from the one of <start_point>, then you                                                           
should clear the index and the working tree right after creating the 
orphan branch by running "git rm -rf ." from the top level of the 
working tree. Afterwards you will be ready to prepare your new files,
repopulating the working tree, by copying them from elsewhere,
extracting a tarball, etc.

— git checkout --help

After you have an empty branch, you’re ready to get started on your jekyll or HTML site with a clean history and a clear conscience.

Written by Caleb Thompson

5 useful tips for a better commit message

Fri, 26 Apr 2013 11:36:00 -0400

You’re already writing decent commit messages. Let’s see if we can level you up to awesome. Other developers, especially you-in-two-weeks and you-from-next-year, will thank you for your forethought and verbosity when they run git blame to see why that conditional is there.

The first line should always be 50 characters or less and that it should be followed by a blank line. Vim ships with syntax, indent, and filetype plugins for Git commits which can help here.
Add this line to your .vimrc to add spell checking and automatic wrapping at the recommended 72 columns to you commit messages.
```
autocmd Filetype gitcommit setlocal spell textwidth=72
```

Never use the -m <msg> / --message=<msg> flag to git commit.

It gives you a poor mindset right off the bat as you will feel that you have to fit your commit message into the terminal command, and makes the commit feel more like a one-off argument than a page in history:

git commit -m "Fix login bug"

A more useful commit message might be:

Redirect user to the requested page after login

https://trello.com/path/to/relevant/card

Users were being redirected to the home page after login, which is less
useful than redirecting to the page they had originally requested before
being redirected to the login form.

* Store requested path in a session variable
* Redirect to the stored location after successfully logging in the user

Answer the following questions:
1. Why is this change necessary?
  
  This question tells reviewers of your pull request what to expect in the commit, allowing them to more easily identify and point out unrelated changes.
2. How does it address the issue?
  
  Describe, at a high level, what was done to affect change. “Introduce a red/black tree to increase search speed” or
  “Remove <troublesome gem X>, which was causing <specific description of issue introduced by gem>” are good examples.
  
  If your change is obvious, you may be able to omit addressing this question.
3. What side effects does this change have?
  
  This is the most important question to answer, as it can point out problems where you are making too many changes in one commit or branch. One or two bullet points for related changes may be okay, but five or six are likely indicators of a commit that is doing too many things.
  
  Your team should have guidelines and rules-of-thumb for how much can be done in a single commit/branch.
Consider making including a link to the issue/story/card in the commit message a standard for your project. Full urls are more useful than issue numbers, as they are more permanent and avoid confusion over which issue tracker it references.

This is generally done as the first paragraph after the summary, on line 3.

Having a story in your git log will make a huge difference in how you and others perceive your project. By taking great care in commit messages, as you do in your code, you will help to increase overall quality.

Special thanks to Tim Pope, whose Note About Git Commit Messages literally sets the standard for a good commit message.

Additional thanks to the creator of Git and a real stickler for a good commit message, Linus Torvalds.

Written by Caleb Thompson

22 Oct 2008 — Simple Test Metrics in Your Rails App, and What They Mean

15 Aug 2009 — A grand piano for your violin

15 Sep 2012 — 8 (new) steps for fixing other people’s code

17 Apr 2012 — Remote Branch

Redis partial word match -- you (auto)complete me

Thu, 25 Apr 2013 09:30:28 -0400

We can use partial word matching to rapidly search strings of text such as Names, Cities, States, etc.

We can do this by indexing strings into Redis sets based on partial matches of the string. The indexing process takes a string and breaks it into left-bound substrings which are placed into the appropriate Redis sets.

Partial word matching movie titles

In this example we’ll enable partial word matching queries of movie titles.

The movie titles will be stored in plain text. The keys are simple key-value pairs that are stored with the key structure movies:id, where id is incremented:

$ redis-cli get movies:1
"Bad Santa"
$ redis-cli get movies:2
"Batman"
$ redis-cli get movies:3
"Bad Company"

The movie Batman would be decomposed into the following sets (assuming that the indexing started at two characters):

ba
bat
batm
batma
batman

We’ll index the movie titles into sets based on partial match of their titles. To prevent any key collisions in Redis we’ll create keys with the following structue index:abc:movies.

View the indexed ids using Redis smembers command:

$ redis-cli smembers index:ba:movies
1) "1"
2) "2"
3) "3"

$ redis-cli smembers index:bat:movies
1) "2"

Note: The keys for the movie titles have been parameterized (lowercase and spaces replaced with dashes).

We’ll use a Ruby class Autocomplete to wrap the Redis calls:

# autocomplete.rb
require 'redis'

class Autocomplete
  def initialize(partial_word)
    @partial_word = partial_word
  end

  def movies
    redis.sort "index:#{partial_word}:movies", by: :nosort, get: 'movies:*'
  end

  private

  def redis
    Redis.current
  end

  attr_reader :partial_word
end

movies = Autocomplete.new('bat').movies

We’ll use the sort command with the by: :nosort parameter to query the partial word match index and return the matched movie names.

Written by Harlow Ward

Episode 45: Tiny Robots Cuddling with other Tiny Robots

Tue, 23 Apr 2013 06:00:30 -0400

Episode 45: Tiny Robots Cuddling with other Tiny Robots:

In this week’s podcast we try something a little different. Joe Ferris, Matt Jankowski, Ben Orenstein, and Chad Pytel get together and have a little fun, in what we’re calling “Tiny Robots cuddling with other Tiny Robots”.

We’d love to get your thoughts on this special format, tweet us @thoughtbot or email learn@thoughtbot.com.

Vim Splits - Move Faster and More Naturally

Thu, 18 Apr 2013 09:30:09 -0400

Most of us are Vim users and have tweaked our favorite editor for speed and convenience. See thoughtbot’s dotfiles.

One of my favorite tools is the window split. Here is a quick splits overview and configurations to use them more effectively.

The basics

Create a vertical split using :vsp and horizontal with :sp.

By default, they duplicate the current buffer. This command also takes a filename:

:vsp ~/.vimrc

You can specify the new split height by prefixing with a number:

:10sp ~/.zshrc

Close the split like you would close vim:

:q

Easier split navigations

We can use different key mappings for easy navigation between splits to save a keystroke. So instead of ctrl-w then j, it’s just ctrl-j:

nnoremap <C-J> <C-W><C-J>
nnoremap <C-K> <C-W><C-K>
nnoremap <C-L> <C-W><C-L>
nnoremap <C-H> <C-W><C-H>

More natural split opening

Open new split panes to right and bottom, which feels more natural than Vim’s default:

set splitbelow
set splitright

Resizing splits

Vim’s defaults are useful for changing split shapes:

"Max out the height of the current split
ctrl + w _

"Max out the width of the current split
ctrl + w |

"Normalize all split sizes, which is very handy when resizing terminal
ctrl + w =

More split manipulation

"Swap top/bottom or left/right split
Ctrl+W R

"Break out current window into a new tabview
Ctrl+W T

"Close every window in the current tabview but the current one
Ctrl+W o

:help!

As with everything in Vim, for more information, check the well-written helpfiles. In Vim, :help splits.

Vim Meetups

Come talk splits at a Vim Enthusiast Meetup near you:

Photo credit: Andrew Ressa on Flickr

Written by Adarsh Pandit.

Online presentation with thoughtbot and Heroku

Tue, 16 Apr 2013 21:11:00 -0400

Adarsh, Alex, and I are giving a free online presentation with Abe from Heroku about how their platform fits into our process. Over 1,400 people have registered so far! The details:

Tomorrow, April 17
Once at 7:00am PST (2:00pm GMT / 7:30pm IST)
A second time at 10:00am PST (5:00pm GMT / 10:30pm IST)

RSVP here.

We will be live coding(!), making a single change to a live web application hosted on Heroku within the context of a common process for us:

Campfire for real-time communication and alerts.
Trello for managing the task and tracking discussion.
Our git protocol.
GitHub pull request-based code review.
Shortcuts from thoughtbot/dotfiles.
Staging and production environments on Heroku.

We will also show a few other goodies:

Heroku config variables.
Heroku addons.
Heroku 2x dynos.
Using Apache Bench for simple load and memory tests.
Each dyno handling about ~1,000 requests per minute for a static site.
Unicorn, Sinatra, and Ruby 2.0’s Copy-On-Write garbage collection.
Using log2viz for performance and memory visibility.

We will share an open source web application and a read-only Trello board during the presentation. There will be a question-and-answer session at the end.

Hope to see you online! RSVP here.

UPDATE: Heroku has posted a recording to YouTube.

Episode 44: I feel the opposite of burnt out

Mon, 15 Apr 2013 10:00:27 -0400

Episode 44: I feel the opposite of burnt out:

In this week’s podcast, Ben Orenstein is joined by Chad Fowler, author, speaker, and CTO of 6wunderkinder. Ben and Chad discuss Chad’s recent move to Berlin and 6wunderkinder, what a CTO does, getting back to coding, the early Ruby community, who Chad wants to hire, predicting success of new hires, and what makes a truly good developer, favorite interview questions, how Chad’s interviewing process has changed over time, how age and experience can change your perspective, how Chad built a great team, and what he might write about in the future. They also discuss Chad’s new tattoo, his regrets, meditation, therapy, gaining control over your mind, and much, much more.

Ruby Science Redesigned

Wed, 10 Apr 2013 13:16:43 -0400

We just pushed a new design for Ruby Science. Previous purchasers and Prime subscribers can grab the update on Learn.

The new design includes a new layout, which is much more appropriate for a book. We updated the typeface and font size to improve the experience when reading the book on a screen as opposed to a printed page. The margin size is also greatly reduced, making it easier to zoom in on a laptop screen and bring the text right to the edges.

Get your copy of Ruby Science today.

Now Available For Free With Learn Prime

We recently announced the launch of our subscription service: 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, as well as access to our private Campfire room, where you can get live help from thoughtbot designers and developers.

Subscribe now.

giant robots smashing into other giant robots

How to write a great README

The Basics

Don’t get lazy just because this is for developers

The code matters

Sandi Metz’ rules for developers

The rules

When to break these rules

100-line classes

Five lines per method

Four method arguments

Only instantiate one object in the controller

Great success!

Google Hangout for Standups and Interviews

Episode 48: Barista imposter syndrome

Ruby Science: You down with OCP?

Now Available For Free With Learn Prime

Reducing Churn in Subscription Services

New screencast: Improving Performance for Real-time Requests

Announcing Learn for iPad

Episode 47: Two hours per minute

Strong parameters as documentation

We're at RailsConf 2013!

Episode 46: We don't have a monopoly on being unhealthy

It's for the orphans!

git checkout --orphan gh-pages

5 useful tips for a better commit message

Related Articles

Redis partial word match -- you (auto)complete me

Partial word matching movie titles

Related Reading

Episode 45: Tiny Robots Cuddling with other Tiny Robots

Vim Splits - Move Faster and More Naturally

The basics

Easier split navigations

More natural split opening

Resizing splits

More split manipulation

:help!

Vim Meetups

Online presentation with thoughtbot and Heroku

Episode 44: I feel the opposite of burnt out

Ruby Science Redesigned

Now Available For Free With Learn Prime

`git checkout --orphan gh-pages`