Hobo 2.0.0 released!

Posted 3 months back at The Hobo Blog

We’re proud to announce the release of Hobo 2.0.0.

Major New Features

• All Javascript code has been completely rewritten. prototype.js is no longer required or supported. We now depend on jQuery and either jQuery-UI or Bootstrap.

• Theming support has been extensively updated. New themes are much easier to write, and multiple themes per application are supported.

• The default theme has been changed to a Bootstrap based theme.

• Support added for the techniques mentioned in this blog post: How Basecamp Next got to be so damn fast without using much client-side UI including two mechanisms for pushState based AJAX and two mechanisms for intelligent hierarchical fragment caching.

• several additional tags have gained AJAX support. This includes, but is not limited to <a>, <filter-menu> and <page-nav>.

• all tags now use the standard Hobo AJAX support mechanism, which used to be known as Hobo form AJAX. The editor tags in particular have changed substantially.

• new tags: nested-cache, swept-cache, live-editor, click-editor, formlet, hot-input, feckless-fieldset, accordion, accordion-collection, autocomplete, combobox, datepicker, dialog-box, tabs and more.

• plugins are now based on the Rails asset pipeline. Available plugins include hobo_jquery_ui, hobo_boostrap_ui, hobo_paperclip, hobo_omniauth, hobo_data_tables, hobo_tokeninput, hobo_simple_color, hobo_tree_table, hobo_mapstraction. Rails, jQuery and Bootstrap plugins can also generally be easily used.

• Rails 3.2 is required, 3.2.12 or greater is strongly recommended.

• many other fixes and updates. See CHANGES for more detailed information.

Installation

• Download and Installation Instructions

• Upgrade Instructions

• Upgrade Tutorial

Regressions

See CHANGES

Changes from Hobo 2.0.0.pre10

HoboSupport’s patches to Chronic have been removed due to incompatibility with Ruby 2.0.0.

Supported Rubies

Hobo 2.0.0 has been tested against 1.8.7-p371, 1.9.3-p374, 2.0.0-p0 and JRuby 1.7.3.

Rails 4 Support

Work has started on Rails 4.0 support for Hobo. No other major features are planned for the next release of Hobo, so we do not expect it to lag too far behind the release of Rails 4.0.

Hobo 2.0.0 released!

Posted 3 months back at The Hobo Blog

We’re proud to announce the release of Hobo 2.0.0.

Major New Features

• All Javascript code has been completely rewritten. prototype.js is no longer required or supported. We now depend on jQuery and either jQuery-UI or Bootstrap.

• Theming support has been extensively updated. New themes are much easier to write, and multiple themes per application are supported.

• The default theme has been changed to a Bootstrap based theme.

• Support added for the techniques mentioned in this blog post: How Basecamp Next got to be so damn fast without using much client-side UI including two mechanisms for pushState based AJAX and two mechanisms for intelligent hierarchical fragment caching.

• several additional tags have gained AJAX support. This includes, but is not limited to <a>, <filter-menu> and <page-nav>.

• all tags now use the standard Hobo AJAX support mechanism, which used to be known as Hobo form AJAX. The editor tags in particular have changed substantially.

• new tags: nested-cache, swept-cache, live-editor, click-editor, formlet, hot-input, feckless-fieldset, accordion, accordion-collection, autocomplete, combobox, datepicker, dialog-box, tabs and more.

• plugins are now based on the Rails asset pipeline. Available plugins include hobo_jquery_ui, hobo_boostrap_ui, hobo_paperclip, hobo_omniauth, hobo_data_tables, hobo_tokeninput, hobo_simple_color, hobo_tree_table, hobo_mapstraction. Rails, jQuery and Bootstrap plugins can also generally be easily used.

• Rails 3.2 is required, 3.2.12 or greater is strongly recommended.

• many other fixes and updates. See CHANGES for more detailed information.

Installation

• Download and Installation Instructions

• Upgrade Instructions

• Upgrade Tutorial

Regressions

See CHANGES

Changes from Hobo 2.0.0.pre10

HoboSupport’s patches to Chronic have been removed due to incompatibility with Ruby 2.0.0.

Supported Rubies

Hobo 2.0.0 has been tested against 1.8.7-p371, 1.9.3-p374, 2.0.0-p0 and JRuby 1.7.3.

Rails 4 Support

Work has started on Rails 4.0 support for Hobo. No other major features are planned for the next release of Hobo, so we do not expect it to lag too far behind the release of Rails 4.0.

Synchronizing Snapshots and Incrementals With Single Threading

Posted 3 months back at Jay Fields Thoughts

Many of the applications that I write these days have a lot of data - so much that there's no reasonable way to continually send all of it. Instead, most of the applications I work with will have the ability to receive a snapshot of the current state, and the ability to receive deltas (incrementals) that must be applied to the previous snapshot. To further complicate things, incomplete data is unaaceptable and ordering matters. This type of environment breeds many solutions for synchronizing snapshots and incrementals. This entry is about using single threading (via jetlang) for synchronization and guaranteed accuracy.

Let's take a very simple example, you have two processes a client and server. The server has a list and the client needs to display that list - completely and in order. The list on the client also needs to be updated whenever the list on the server is updated.

There are several issues that you could encounter in a multithreaded environment.

• If you request a snapshot and then start listening to incrementals, you may miss data that isn't in the snapshot, but was broadcast before you started listening to incrementals
• If you start listening to incrementals and request a snapshot at the same time, you may apply an incremental to the snapshot, even though the snapshot already reflects the incremental.
• If you start listening to the incrementals first, you'll need some way to throw away the incrementals that are already reflected in the snapshot.

It's time to get into some code.

Here's some simple server code.

<script src="https://gist.github.com/jaycfields/5021245.js"></script>
The above code contains a server-list, which is a list that represents the ordered random numbers being generated on the server side. Our task is to mirror this list in our client. The appending scheduled task and appending fiber are stored to allow for easy starting and stopping of appending. The server-start and server-stop functions are provided for convenience, should you choose to run this example locally.

The subscriber atom and the subscribe function are a simple way for a client to subscribe to snapshots and incrementals. The publish-to-client function derefs a fn and immediately calls it with a snapshot or incremental. In a prod application, publish and subscribe logic would probably involve a socket or messaging system - our solution is purposefully naive, to focus on the point of the post: synchronization.

The get-snapshot function publishes the current state of the the server-list to a client. The append-to-list function is removing elements so it's easy to see the server-list changing - without the data growing to an unmanageable size, in prod this would (likely) not exist; however, the rest of the code in append-to-list is fairly representative of a common practice - generate a delta, apply it to the local list and publish it out to clients.

Looking at this code, it's easy to see that one fiber is appending to the list and publishing to the client, while another fiber would return the value of get-snapshot. This code can work, but the way it's currently written data accuracy cannot be guaranteed.

Let's look at some client code.

<script src="https://gist.github.com/jaycfields/5021379.js"></script>
The client-start function subscribes to server updates, and then requests a snapshot. The handle update function resets a client-list on snapshot and conjs an incremental to the existing list. (note: the client list is kept at 10 elements for simplicity, just like the server - I would not expect this type of code to be in prod).

Below is a full snapshot of the current code.

<script src="https://gist.github.com/jaycfields/5021399.js"></script>
The client and server code is the same as above, but this example also contains some function calls in a comment. At this point you can paste this code into your favorite editor, start the client and the server and inspect both lists. The update frequency is so large that you can even compare the two lists, and it's highly likely that they are equal.

For a lot of problems this code may be sufficient; however, as we noted above, there is definitely an opportunity for you to see invalid state. With this specific code the append fiber could update the atom with an incremental X, on the main fiber get-snapshot could deref a snapshot with X included (and publish it) and then the append fiber could also publish the incremental X. Luckily there's a simple solution, publish the snapshot, update the server-list, and publish the incrementals all on the same fiber.

The code below shows how easy it is to create a jetlang fiber and execute an anonymous function.

<script src="https://gist.github.com/jaycfields/5021477.js"></script>
As you can see, very little changed with the code. We've defined another fiber, synchro-fiber, which we will use to single thread our updates to server-list and our publishes to the client. The synchro-fiber will execute the runnables (in our example, anonymous functions) that are put on it's queue, in order. The body of get-snapshot and append-to-list were slightly modified to call the execute function with their previous body as an anonymous function. Other technical differences are also true - the code isn't immediately run, it's no longer blocking, and the return value has been altered. While all of these observations are true, they are irrelevant with respect to what we were trying to accomplish.

Using jetlang fibers we've accomplished our goal - we can guarantee that snapshots and incrementals will be easy to synchornize (without sequence ids), accurate, and in order. Of course, you'll need to consume both of these messages on a single fiber as well, but that should be equally easy to accomplish.

Client-side MVC is not a silver bullet

Posted 3 months back at mir.aculo.us - Home

This is an edited repost of a comment of mine on Amy’s blog post about why we shut down Charm.

Charm, as it is, is using Backbone.js, Underscore.js and Zepto on the front-end, and Rails 2.3, Postgres, memcached, redis, resque, and for websockets Sinatra, and a few other things. The front-end is communicating with the back-end via a JSON API.

I’ve come to the realization that this much client-side processing and decoupling is detrimental to both the speed of development, and application performance (a ton of JavaScript has to be loaded and evaluated each time you fire up the app). It’s better to let the server handle HTML rendering and minimize the use of JavaScript on the client. You can still have fast and highly interactive applications, as the new Basecamp shows—letting the server handle most stuff doesn’t mean that you have to cut back on cool front-end features and user friendliness.

I argue that all these newfangled libraries are actually detrimental to the user experience in some ways, as they lock you into certain patterns (it’s hard do to things the authors didn’t anticipate) and if you use something like Ember (which we didn’t), it’s even worse as all applications using it practically look the same (many people choose using Twitter’s Bootstrap library, for example).

We’ve spend a lot of time getting Backbone to work properly, and the ease-of-use quickly deteriorates when your models get more complex. It’s a great choice for simple stuff, but email is far from simple. We also had to add yet an other extra layer of processing to generate “ViewModels” on the server because the normal Rails serialization of objects wouldn’t cut it.

What you end up with is building a layer cake that doesn’t add any value and slows down development. Especially when you’re starting out and need to stay flexible you don’t want to have too much code around—and Rails is great for that, but… adding a JSON API layer and basically a second application that runs on the client is annihilating this advantage for you.

All in all, my current recommendation for SaaS-type web apps is: Rails 2.3 (or Rails 3.2 if you prefer), a Postgres database, as much HTML generation on the server as possible and augment that with RJS (Rails’ mechanism to push JavaScript snippets to the client that get eval’d). This allows for direct re-use of server-side templates, and it’s simple, and works well. As an added bonus, keeping things on the server allow for much better error and performance monitoring and thus quicker turnaround for fixes. There’s also a lot of great stuff in this direction coming up in Rails 4 (like Turbolinks, a sort-of-successor to PJAX, which is a handy replacement for RJS if you don’t like it).

Alas, keep it simple and don’t repeat yourself.

Episode 37: You're riding the Rails bro!

Posted 3 months back at GIANT ROBOTS SMASHING INTO OTHER GIANT ROBOTS - Home

Episode 37: You're riding the Rails bro!:

Ben Orenstein is joined this week by Joe Ferris, CTO of thoughtbot. Ben and Joe discuss starting a new Rails project and our Rails application generator, Suspenders, test spies and breaking up your tests, and using Rails beta versions.

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

rdoc 4.0.0

Posted 3 months back at Segment7

• home
• rdoc
• bugs

RDoc produces HTML and command-line documentation for Ruby projects. RDoc includes the +rdoc+ and +ri+ tools for generating and displaying documentation from the command-line.

Changes

RDoc 4.0 includes several new features and several breaking changes. The changes should not affect users of rdoc or ri.

Notable feature additions are markdown support and an WEBrick servlet that can serve HTML from an ri store. (This means that RubyGems 2.0+ no longer needs to build HTML documentation when installing gems.)

Changes since RDoc 3.12.1:

• Breaking changes

  • The default output encoding for RDoc is now UTF-8. Previously RDoc used the default external encoding which was determined from your locale. Issue #106 by Justin Baker.

  • RDoc::RI::Store is now RDoc::Store so ri data generated by RDoc 4 cannot be read by earlier versions of RDoc. RDoc::RI::Store exists as an alias of RDoc::Store so ri data from older versions can still be read. RDoc::RI::Store will be removed in RDoc 5.

    Tests that create RDoc::CodeObjects on the fly without wiring them into the documentation tree (did not use add_class, add_method, etc.) must be updated to use these methods. The documentation tree automatically attaches them to the store instance which allows lookups to work correctly. Additionally, a new method RDoc::Store#add_file must be used instead of RDoc::TopLevel.new. The latter will not be attached to the documentation tree.

  • RDoc generators must accept an RDoc::Store and an RDoc::Options in initialize. RDoc no longer passes an Array of RDoc::TopLevel objects to #generate. Use RDoc::Store#all_files instead.
  • Some markup formatters (RDoc::Markup::To*) now accept an RDoc::Options instance as the first argument. Notably, the base class Formatter and ToHtml*. (This is not universal due to the difficult at accessing the user's options instance deep inside RDoc. A future major release may remedy this.)
  • Added new markup nodes and specials that RDoc::Markup::Formatter subclasses must handle. If you're using RDoc::Markup::FormatterTestCase the new methods you need to add should be readily apparent.
  • Removed RDoc::RI::Paths::SYSDIR and ::SITEDIR. These were hidden constants so no breakage is expected. Use RDoc::RI::Paths::systemdir and ::sitedir instead.
  • RDoc::RI::Store#modules has been renamed to RDoc::Store#module_names to avoid confusion with RDoc::Store#all_modules imported from RDoc::TopLevel.
  • RDoc::RDocError has been removed. It was deprecated throughout RDoc 3.
  • ri -f html is no longer supported.
  • Comment definitions in C comments are now only discovered from the first line. A colon on a subsequent line won't trigger definition extraction. Issue #103, see also http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/42942
  • Fixed :stopdoc: for class A::B where A has not been seen. Issue #95 by Ryan Davis
  • RDoc::ClassModule#each_ancestor no longer yields itself if there is circular ancestry

• Major enhancements

  • ri can now show pages (README, etc.)

    ri rdoc:README

    Will show the README for the latest version of RDoc. You can specify exact gem versions such as "rdoc-4.0:README" or view pages from the standard library documentation with "ruby:README".

    RDoc 3 did not save pages in ri data so you will need to regenerate documentation from your gems to use this feature.

  • Added Markdown as a supported format. The markdown format can be set on a per-file or per-comment basis with the +:markdown:+ directive like the rd and tomdoc formats and on a per-project basis with rdoc --markup markdown --write-options

  • Removed global state from RDoc. RDoc::Store holds the documentation tree and connects the driver to the parsers and generator. This also allows documentation parsing and generation for multiple instances, but the rdoc command-line tool does not support this.

    Due to this change RDoc::RDoc.current and RDoc::RDoc.reset no longer exist.

• Minor enhancements

  • Added --page-dir option to give pretty names for a FAQ, guides, or other documentation you write that is not stored in the project root. For example, with the following layout:

    README.txt guides/syntax.txt guides/conversion.txt

    Running rdoc --page-dir guides will make the files in "guides" appear to be at the top level of the project. This means they will appear to exist at the top level in HTML output and you can access them with ri your\_gem:syntax and ri your\_gem:conversion.

  • Added --root for building documentation from outside the source dir.
  • Added current heading and page-top links to HTML headings.
  • Added a ChangeLog parser. It automatically parses files that begin with 'ChangeLog'
  • Added a table of contents to the sidebar.
  • RDoc markup format merges adjacent labels in a label or note list into a single definition list item for output.
  • RDoc now tracks use of extend. Pull request #118 by Michael Granger.
  • RDoc now tracks methods that use super. Pull request #116 by Erik Hollensbe.
  • Added methods ::systemdir, ::sitedir, ::home_dir and ::gem_dir to fetch the components of RDoc::RI::Paths.path individually.
  • Added support for rb_file_const.
  • RDoc now processes files in sorted order. Issue #71 by Vít Ondruch
  • RDoc now warns with --verbose when methods are duplicated. Issue #71 by Vít Ondruch
  • ri will display documentation for all methods in a class if -a is given. Issue #57 by casper
  • The RDoc coverage report will report line information for attributes, constants and methods missing documentation. Issue #121 by Zachary Scott
  • RDoc now reports a warning for files that are unreadable due to permissions problems.
  • RDoc controls documentation generation for RubyGems 2.0+

• Bug fixes

  • Fixed parsing of multibyte files with incomplete characters at byte 1024. Ruby bug #6393 by nobu, patch by Nobuyoshi Nakada and Yui NARUSE.
  • Fixed rdoc -E. Ruby Bug #6392 and (modified) patch by Nobuyoshi Nakada
  • Added link handling to Markdown output. Bug #160 by burningTyger.
  • Fixed HEREDOC output for the limited case of a heredoc followed by a line end. When a HEREDOC is not followed by a line end RDoc is not currently smart enough to restore the source correctly. Bug #162 by Zachary Scott.
  • Fixed parsing of executables with shebang and encoding comments. Bug #161 by Marcus Stollsteimer
  • RDoc now ignores methods defined on constants instead of creating a fake module. Bug #163 by Zachary Scott.
  • Fixed ChangeLog parsing for FFI gem. Bug #165 by Zachary Scott.
  • RDoc now links #=== methods. Bug #164 by Zachary Scott.
  • Allow [] following argument names for TomDoc. Bug #167 by Ellis Berner.
  • Fixed the RDoc servlet for home and site directories. Bug #170 by Thomas Leitner.
  • Fixed references to methods in the RDoc servlet. Bug #171 by Thomas Leitner.
  • Fixed debug message when generating the darkfish root page. Pull Request #174 by Thomas Leitner.
  • Fixed deletion of attribute ri data when a class was loaded then saved. Issue #171 by Thomas Leitner.
  • Fully qualified names for constants declared from the top level are now attached to their class or module properly.
  • Fixed table of contents display in HTML output for classes and modules.
  • Incremental ri builds of C files now work. C variable names from previous runs are now saved between runs.
  • A word that is directly followed by a multi-word tidy link label no longer disappears. (Like text{link}[http://example])
  • Fixed legacy template support. Pull Request #107 by Justin Baker.
  • An HTML class in a verbatim section no longer triggers ruby parsing. Issue #92 by Vijay Dev
  • Improved documentation for setting the default documentation format for your ruby project. Issue #94 by Henrik Hodne
  • Fixed handling of LANG in the RDoc::Options tests. Issue #99 by Vít Ondruch
  • RDoc no longer quits when given an entry that is not a file or directory. Issue #101 by Charles Nutter
  • Fixed bug in syntax-highlighting that would corrupt regular expressions. Ruby Bug #6488 by Benny Lyne Amorsen.
  • "class Object" no longer appears in the coverage report if all its methods are documented. This suppresses a false positive for libraries that add toplevel methods. Pull Request #128 by Zachary Scott.
  • Fixed testgenurl test name in TestRDocMarkupToHtml. Pull Request #130 by Zachary Scott.
  • Comment-defined methods ahead of define_method are now discovered. Issue #133 by eclectic923
  • Fixed detection of define_method documentation. Issue #138 by Marvin Gülker.
  • Fixed lexing of character syntax (?z). Reported by Xavier Noria.
  • Add license to gem spec. Issue #144 by pivotalcommon
  • Fixed comment selection for classes. Pull request #146 by pioz
  • Fixed parsing of def self.&() end. Issue #148 by Michael Lucy
  • Generated RD parser files are now included in the gem. Issue #145 by Marvin Gülker
  • Class and module aliases now create new classes to avoid duplicate names in the class list. Issue #143 by Richard Schneeman, Rails Issue #2839
  • RDoc::Markup::Parser now correctly matches indentation of lists when multibyte characters are used in the list labels. Issue #140 by burningTyger
  • Fixed mangling of email addresses that look like labels. Issue #129 by Tobias Koch
  • Classes and modules in a C file may now be created in any order. Issue #124 by Su Zhang
  • A metaprogrammed method supports the :args: directive. Issue #100
  • A metaprogrammed method supports the :yields: directive.
  • RDoc will now look for directives up to the end of the line. For example, class B < A; end # :nodoc: will now hide documentation of B. Issue #125 by Zachary Scott
  • Fixed tokenization of % when it is not followed by a $-string type
  • Fixed display of _END_ in documentation examples in HTML output
  • Fixed tokenization of reserved words used as new-style hash keys
  • RDoc now handles class << $gvar by ignoring the body
  • Fixed parsing of class A:: B.
  • Worked around bug in RDoc::RubyLex where tokens won't be reinterpreted after unget_tk.
  • Fixed class << ::Foo writing documentation to /Foo.html
  • Fixed class ::A referencing itself from inside its own namespace.

Changes since RDoc 4.0.0.rc.2:

• Bug fix
  • Templates now use the correct encoding when generating pages. Issue #183 by Vít Ondruch

Menubar productivity

Posted 3 months back at mir.aculo.us - Home

OS X is awesome and that’s why we (neckbeard-less?) developers love it. Of course not everything is perfect, and one area of contention is the menu bar. There tends to be a never-ending supply of icons that fill it up and destroy its usefulness due to information overload.

There’s even tools that help you organize your menu bar, but I think that’s just fighting symptoms and not a permanent solution. Anyway, these tools are not for me, and I’ve decided to put my menu bar on a diet.

Here is what I currently use:

Icons, from left to right, and why I use them:

• Dropbox—so I see if stuff is synced. I use the black & white icon.
• gfxCardStatus—so I see which graphics card my MacBook Pro uses, and to force it into using discrete graphics if browsers start to have graphical glitches, which is unfortunately quite often.
• Hackpad—we do most internal brainstorming and copywriting on Hackpad. (Hey Hackpad, update your icon for my retina screen!)
• Little Snitch—hovering over the icon shows Little Snitch’s nifty network monitor.
• iStat Menus 4 CPU monitor—helpful during development and has shortcuts to launch Activity Monitor and other tools.
• Time Machine—I like to see that it’s doing stuff when I have my backup drive connected at the office.
• Keyboard & Character Viewer—I use OS X’s Character Viewer tool ⓐⓛⓛ ⓣⓗⓔ ⓣⓘⓜⓔ.
• Bluetooth—useful at the office for my external keyboard, mouse and trackpad.
• Wi-Fi—essential.
• iStat Menus 4 battery—more info than OS X’s default icon.
• Volume control—I use the keyboard to change the volume, but option-clicking the icon allows you to quickly set input and output devices.
• iStat Menus 4 clock—I like the “fuzzy clock” and the dark grey calendar icon.

And that’s it. YMMV.

How and why to Splunk with Heroku

Posted 3 months back at GIANT ROBOTS SMASHING INTO OTHER GIANT ROBOTS - Home

Splunk is company that offers logging services. They went public last year, have a market cap of over $3 billion, and are headquartered in San Francisco’s SoMa neighborhood.

I’ve tried Loggly and Papertrail. In my opinion, Splunk is the best of the bunch due to its:

• Real-time or very-near-real-time data discovery.
• Wildcard search.
• Timespan dragging.

Loggly and Papertrail offer Heroku add-ons but Splunk doesn’t. So, setup is a bit more complex with Splunk. Here’s how to do it.

Go to Splunk Storm. Create an account.

Once signed in, create a project:

You can start with a free plan:

Click “Network data”:

Click “Authorize your IP address”:

Click “Automatically”:

You now have 15 minutes to send Splunk data. Copy the URL in the text box:

Then, add a Heroku syslog drain:

heroku drains:add logs4.splunkstorm.com:20942

Perform a few activities on your app to send data to the drain. Then, click “Explore data”:

Perform a search, maybe using wildcards:

I haven’t been diligent about saving common searches. If you have generic saved Splunk searches, please share them in the comments of this article.

Filter by dragging a timespan:

Watch how quickly the data loads.

On Rails apps, the default production log level includes useful data. I suggest only changing it to DEBUG when you’re actually debugging:

heroku config:add LOG_LEVEL=DEBUG

That will print SQL queries to the logs, which can be useful but may also contain sensitive data as config.filter_parameters does not apply to SQL queries.

Ruby Science: Extracting and Using Classes

Posted 3 months back at GIANT ROBOTS SMASHING INTO OTHER GIANT ROBOTS - Home

Today’s release of Ruby Science includes three new chapters. If you’re already reading Ruby Science, make sure to grab the latest version.

This week’s updates include tips on safely extracting classes, as well as a specific example of extracting Value Objects. In addition, we discuss how you can use Ruby’s classes-as-objects attitude to eliminate the need for most abstract factory classes.

The book is a work in progress, and currently contains around 123 pages of content. A $49 purchase gets you access to the current release of the book, all future updates, and the companion example application. In addition, purchasers have the ability to send thoughtbot their toughest Ruby, Rails, and refactoring questions.

Get your copy of Ruby Science today.

Pick your compass metric

Posted 3 months back at Too-biased - Home

One of the most important tasks as a leader in a startup is to pick the right metric to track. This is often referred to as the 'compass metric' because it will be your compass for growth. It's important to note that 'compass metrics' will likely change over the lifetime of a business.

Let’s say you started a new social network. When it’s time to pick your first compass metric, you settle on tracking the sum of people who log in on a given day: Daily Active Users ('DAU').

Good pick. It’s hard to misrepresent a metric like DAU. If people don’t like your service, they will likely not return, and your DAU will fall over time. Another metric you could have picked is daily sign ups. This would also give you a good sense of progress, but it’s not nearly as robust. Although you want sign ups, they aren’t necessarily synonymous with the health of your business. By spending a lot of money on marketing you might get a lift in sign ups, but if none of these sign ups ever return, your metrics would tell a misleading story. Daily sign ups look great, but without daily active (and engaged) users you’re just filling up a leaking funnel.

The metric you decide on will be your compass for growth. You implicitly tell your team that if someone moves this metric in the right direction they are doing a good job. If you launch a lot of experiments you can sometimes allow people to use other metrics for some early readings, but you should only conclude the efficacy of your experiments by checking the impact on your compass metric.

After you settled on the compass metric, you have to choose a time frame. This is important because you want to have a very tight feedback loop. If you have a 6-month sales cycle and your chosen metric is bookings, then it’s very hard to properly experiment.

Lastly, you have to design the user interface for your tracking. How exactly are you going to keep your entire team informed? From which angle are you going to look at your metric? As an absolute number ($10,000 in bookings this month), or as a relative number (30% growth over the last quarter)?

Let’s take Shopify as an example. We are a fairly complex business with (thankfully) many different streams of revenue. Most of our money comes from customers that pay us subscription fees. After a lot of experimentation, we concluded that the best compass metric for Shopify is weekly CMRR growth.

CMRR?

CMRR stands for Committed Monthly Recurring Revenue. From Bessmer’s cloud computing law #2:

[…] To achieve better business visibility, most top performing cloud companies focus on Annual Contract Value (ACV) or Monthly Recurring Revenue (MRR) - the combined value of all of the current recurring subscription revenue - instead of bookings. We recommend companies actually take this a step further and track the forward view of Committed Monthly Recurring Revenue (CMRR). The CMRR differs from the MRR in two ways. Firstly, it includes both “in production” recurring revenues of the customer and the signed contracts going into production. Secondly, it is reduced by “churn” which is the MRR expected to be lost from customers that are anticipated to be ending service in the future. CMRR gives you the most pure forward view of the “steady state” revenue of the business based on all the known information today. This is the single most important metric for a cloud business to monitor, as the change in CMRR provides the clearest visibility into the health of any cloud business.

In short, you take the monthly value of all your active customers, plus committed sign-ups and upgrades, minus the monthly value of all your downgrades and churn. Then you calculate the growth of that number compared to last week.

Our internal goal is to reach 3% weekly growth, a very ambitious number given our size. The user interface is simple. Monday mornings, our system sends an email to the team:

Red ✘ if we fell short, green ✔ if we made it. Everyone gets it.

Most groups that have a direct CMRR impact also get their own versions of this email that reports how their group did compared to everyone else.

Weekly meeting

Every Thursday we have a quick funnel meeting. This meeting is attended by everyone who has a direct impact on the CMRR number, including those in sales, marketing, partnerships, etc. Everyone in attendance shares two things:

• What have we learned this week
• What we are going to do differently next week

This is the motor of a fast-growing multi-million dollar venture-backed business. Our growth comes from a combination of choosing the right time intervals (1 week), the right compass metric (CMRR), and the right perspective (week over week growth). There is only a minor amount of support scaffolding built into this structure: one email and one meeting a week. Everything else flows from that.

thoughtbot Drinkup in Paris, France I’ll be in Paris next...

Posted 3 months back at GIANT ROBOTS SMASHING INTO OTHER GIANT ROBOTS - Home

thoughtbot Drinkup in Paris, France

I’ll be in Paris next week and we’re sponsoring a social event at MKP Opera on Thursday, February 28th at 7:30pm. RSVP here

I hope to see you there.

I’ll also be holding office hours while in Paris, so if you won’t be able to make it, or your like to get together to discuss technology, design, or business tweet me at @cpytel and we’ll coordinate a time.

2.0.0.pre10

Posted 3 months back at The Hobo Blog

Sure enough, the bug fix in 2.0.0.pre9 had a regression: some of the cancel links were broken. So here’s a 2.0.0.pre10. I definitely hope to have 2.0.0 final available soon.

We’ve also added a new tutorial upgrading a Hobo 1.0 app to Hobo 2.0.