amp-pure 0.5.0

data/site/src/about/index.haml

@@ -0,0 +1,33 @@
+!!! 1.1
+%html{ :xmlns => "http://www.w3.org/1999/xhtml" }
+  %head
+    %meta{ :content => "text/html; charset=UTF-8", "http-equiv" => "Content-Type" }
+    %title
+      Amp | Version Control Revolution | About Amp
+    = stylesheets :reset, :amp, :all_themes
+    = javascripts "jquery-1.3.2.min.js", "jquery.cookie.js"
+  %body.oneColFixCtr
+    = render("include/_header.haml", :selected => "about")
+    .infopage#container
+      .body-width
+        .floatleft{ :style => "width:90%; padding:8px 0em 6px; margin-left:5%;"}
+          %h2 About #{blue_amp "Amp"}
+          %p
+            #{blue_amp "Amp"} is a general-purpose version-control system. It currently implements #{hg_link}, and we hope to support #{git_link}, #{link_to "http://bazaar-vcs.org/", "bazaar"}, #{link_to "http://subversion.tigris.org/", "svn"}, #{link_to "http://www.nongnu.org/cvs/", "cvs" }, and #{link_to "http://darcs.net/", "darcs" } in the future. Why? Well, that leads us to the question: "Why #{blue_amp "Amp"}?"
+          %h2 #{blue_amp "Amp"} is NOT:
+          %p
+            #{blue_amp "Amp"} does not define a repository format, and most likely never will.
+          %h2 Then why make a VCS?
+          %p
+            #{blue_amp "Amp"} exists because there's plenty of excellent repository formats out there, but none of them are truly good <em>software</em>. We chose #{hg_link} as our first VCS to implement because it comes closest to what we feel is a solid user experience, and that's what we're building upon.
+            %br/
+            %br/
+            #{blue_amp "Amp"} exists to make VCS work for you. Want to add your own commands? #{commands_link "Write a few lines of code"}. Want to use git's commands on a Mercurial repository, switches and all? #{blue_amp "Amp"} is #{workflows_link "working on it"}. Our goal is to produce a piece of software that lets you forget that you're working on #{git_link} project one moment and a #{hg_link} project the next.
+          %h2 #{blue_amp "Amp"}'s Features
+          %ul.bullets{:style => "margin-left:2em;"}
+            %li #{workflows_link "Workflows"} - customizable command sets (e.g. git's commands, svn's commands)
+            %li #{commands_link "Commands"} - work with your VCS on your terms
+            %li #{ampfile_link "Ampfiles"} - tweak amp's settings for a specific repository with one file
+            %li Want more features? #{link_to "/contribute/", "Help develop"} #{blue_amp "Amp"}! We've got a lot planned! 
+          
+    = render("include/_footer.haml")

data/site/src/about/performance.haml

@@ -0,0 +1,31 @@
+!!! 1.1
+%html{ :xmlns => "http://www.w3.org/1999/xhtml" }
+  %head
+    %meta{ :content => "text/html; charset=UTF-8", "http-equiv" => "Content-Type" }
+    %title
+      Amp | Version Control Revolution | Ampfiles
+    = stylesheets :reset, :amp, :all_themes
+    = javascripts "jquery-1.3.2.min.js", "jquery.cookie.js"
+  %body.oneColFixCtr
+    = render("include/_header.haml", :selected => "about")
+    .infopage#container
+      .body-width
+        .floatleft{ :style => "width:90%; padding:8px 0em 6px; margin-left:5%;"}
+          %h2 Amp Performance
+          %p
+            We want #{blue_amp} to be fast. Like, as fast as possible. The biggest problem: Ruby isn't very fast. So here's our current goal: <b>we want #{blue_amp} to be as fast as mercurial</b>.
+          %p
+            #{hg_link "Mercurial"} is written in Python, which according to the #{link_to "http://shootout.alioth.debian.org/", "Great Language Shootout"} is #{link_to "http://shootout.alioth.debian.org/u64q/benchmark.php?test=all&lang=python&lang2=ruby&box=1", "3-10 times slower than Python"}. That's for MRI 1.8.6 - here's a link to #{link_to "http://shootout.alioth.debian.org/u64q/benchmark.php?test=all&lang=python&lang2=jruby&box=1", "JRuby"} and #{link_to "http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=yarv&lang2=python&box=1", "Ruby 1.9"}, which are similar though an improvement.
+          %h2 So how's that going?
+          %p
+            We hope to have some direct, auto-generated benchmarks up here soon. But for now - many amp operations are <b>only 1.5-2 times slower than Mercurial</b>. That's within the range that the language barrier is the major factor. Of course, we hope to do better.
+          %h2 Measuring Amp Performance
+          %p
+            What's interesting about #{blue_amp} is that most applications concerned with speed are optimizing long-running processes. Servers, web apps, graphics processes come to mind. But #{blue_amp} is completely different - VCS clients are invoked dozens of times a day. We need the process to just end fast. That means it needs to start quickly, run quickly, and clean up quickly.
+          %p
+            We're finding a lot of ways to achieve this, and will be writing some blog posts now that #{blue_amp} is being looked at.
+          %h2 How can I help?
+          %p
+            Head on over the #{contribute_link} page and join us! There's plenty of places where we can optimize code (or even if you want to help get some auto-generated benchmarks on this page, that'd be awesome too!)
+          
+    = render("include/_footer.haml")

data/site/src/about/workflows.haml

@@ -0,0 +1,34 @@
+!!! 1.1
+%html{ :xmlns => "http://www.w3.org/1999/xhtml" }
+  %head
+    %meta{ :content => "text/html; charset=UTF-8", "http-equiv" => "Content-Type" }
+    %title
+      Amp | Version Control Revolution | Amp Workflows
+    = stylesheets :reset, :amp, :all_themes
+    = javascripts "jquery-1.3.2.min.js", "jquery.cookie.js"
+  %body.oneColFixCtr
+    = render("include/_header.haml", :selected => "about")
+    .infopage#container
+      .body-width
+        .floatleft{ :style => "width:90%; padding:8px 0em 6px; margin-left:5%;"}
+          %h2 What's a workflow?
+          %p
+            This might be a little confusing. We coined this term for ourselves before we realized that #{link_to "http://www.bazaar-vcs.org/", "bazaar"} had their own workflows. Ours are different. A workflow in #{blue_amp} parlance is <b>a set of commands that go together.</b> #{blue_amp "Amp"} currently has a #{hg_link} workflow: a set of commands that mimics #{hg_link}'s command interface. There is a 1-1 mapping between (most of) Mercurial's commands and the commands in the hg workflow. We're still working on matching them exactly, but we're close.
+          %h2 When does this get interesting?
+          %p
+            It gets interesting because we're working on a #{git_link} workflow. So, if you cut your teeth on git but are working on a project using Mercurial, we're going to let you use git's commands. Think about it - almost all of the basic operations in git have a similar command in Mercurial. The difference are in basic command syntax ( #{shellscript "git push origin master"} vs #{shellscript "hg push"} ) and in the options.
+          %h2 Why do options matter?
+          %p
+            The allowed options matter because they're what we get used to in our command-line software, and there often <i>is not</i> analogous options between VCS clients. #{git_link "Git"} has #{shellscript "git commit --reuse-message=123"}, but there's no such option in #{hg_link}. That's just one point. When you use the same software for long, you develop sets of options you get used to. Switch to a project with a different VCS, and your favorite options aren't there. Annoying. Think of workflows as theming your VCS.
+          %h2 How do I change my workflow?
+          %p
+            #{shellscript "amp workflow git"}. Or #{shellscript "amp workflow hg"}.
+          %h2 Git != Mercurial
+          %p
+            The fact remains that the different VCS systems have different commands, in part, because the underlying repositories are different. Git allows for destructive operations in it's repository and exposes that in in some of its options and commands. Mercurial doesn't allow it. So what happens when you do a #{shellscript "git filter-branch"} on a #{hg_link} repository?
+          %p
+            %b It will fail, and tell you that you requested an impossible action. Rely on that.
+          %h2 The git workflow sucks.
+          %p
+            We know. We're working on it. But #{commands_link "writing commands"} is actually pretty easy - do you want to #{contribute_link "help us out"}?
+    = render("include/_footer.haml")

data/site/src/contribute/index.haml

@@ -0,0 +1,65 @@
+!!! 1.1
+%html{ :xmlns => "http://www.w3.org/1999/xhtml" }
+  %head
+    %meta{ :content => "text/html; charset=UTF-8", "http-equiv" => "Content-Type" }
+    %title
+      Amp | Version Control Revolution | Contribute
+    = stylesheets :reset, :amp, :all_themes
+    = javascripts "jquery-1.3.2.min.js", "jquery.cookie.js"
+  %body.oneColFixCtr
+    = render("include/_header.haml", :selected => "contribute")
+    .infopage#container
+      .body-width
+        .floatleft{ :style => "width:90%; padding:8px 0em 6px; margin-left:5%;"}
+          %h2 How can I help?
+          %p
+            There's a ton you can do! We need people to write nice fancy writeups for the site, and we need developers who can add features. We've got #{link_to "#list", "lots of places you can help"}, and a #{link_to "#features", "good list of features"} we want to develop to reach #{blue_amp}'s goals, and developers will make that easier! Here's our online resources you can use to help:
+          %ul.bullets{:style => "margin-left:2em;"}
+            %li The #{link_to "http://bitbucket.org/carbonica/amp/", "BitBucket source"}. We accept pull requests!
+            %li Our #{link_to "http://github.com/michaeledgar/amp", "GitHub mirror"}. We accept GitHub pull requests!
+            %li We use #{link_to "http://bitbucket.org/carbonica/amp/issues/?status=new&status=open", "BitBucket's issue tracker."}...
+            %li ... and BitBucket's #{link_to "http://bitbucket.org/carbonica/amp/wiki/Home", "wiki, too."}
+            %li Lastly, we've got a #{link_to "http://groups.google.com/group/amp-vcs/", "Google Group"}.
+          %h2 OK, but how do I submit code?
+          %p
+            #{blue_amp "Amp"} is run on a "commit bit" policy. Get one patch approved, and you have full repo access. Our source is #{link_to "http://bitbucket.org/carbonica/amp/", "hosted at BitBucket"} - just fork us and send a pull request. 
+          %p 
+            We don't have strict requirements about how you format your patch, but keep in mind that we have to verify your patch is good before we accept the pull. So here's a list of things that will make that faster if you are submitting code:
+          %ul.bullets{:style => "margin-left:2em;"}
+            %li Try to stick to the #{link_to "/contribute/style.html", "code style guidelines"}.
+            %li Include tests! Not required, but it certainly makes it easier to check if your patch works.
+            %li Document your new code! Methods are always documented in #{blue_amp} - end of story. 
+            %li Comments-in-code are great for non-trivial algorithms, but we'll be the first to admit our code doesn't have enough inline comments.
+            %li Provide some way for us to know what your patch does - even if you think it's obvious.
+          %p
+            Again, these aren't requirements, but we want you to work on #{blue_amp}, which means we want to approve your patches!
+          %a{:name => "list"}
+          %h2 I'm ready to jump in! Any ideas?
+          %p
+            Here's a list of things to think about, in order from least-to-most effort required:
+          %ul.bullets{:style => "margin-left:2em;"}
+            %li Write for this site! The source for the website is actually stored in the amp repository - a #{shellscript "rake build-website"} will rebuild the site from the source. We like write-ups on major amp features, especially, but anything you think could help, send it in!
+            %li Clean up code in general. If you see code violating style guidelines, fix it up. If you see obvious silliness (branches that never execute, superfluous conditionals, so on) then lend a hand and patch it up!
+            %li Comment existing code. Some methods are undocumented, some enormous methods don't have inline comments explaining things.
+            %li Write tests! We don't have nearly enough tests, and we want to maximize both unit test (where possible) and functional test coverage.
+            %li Ruby-tize the code. There are places where, in our innocent pursuit to port #{hg_link} to Ruby, we directly ported algorithms. We apologize. Help us make it idiomatic.
+            %li Fix bugs on #{lighthouse_link}. These might be simple fixes, they might not. Either way, we'll give you an e-hug.
+            %li Refactor huge methods. There's a few instances where there are simply enormous, mind-numbing methods that need to be cleaned up. They're often the most important methods too, which is probably why nobody has done it yet. Be a hero.
+            %li Take a look at our #{link_to "#features", "feature hit-list"}. These are major goals we hope to achieve in #{blue_amp}'s development. The core team focuses on these when possible.
+          %h2 Feature Hit-List
+          %p
+            These are the features that take the most work, and are the most important to #{blue_amp}'s development.
+          %a{:name => "features"}
+          %ul.bullets{:style => "margin-left:2em;"}
+            %li Support for other repository formats: #{git_link}, #{link_to "http://bazaar-vcs.org/", "bazaar"}, #{link_to "http://subversion.tigris.org/", "svn"}, #{link_to "http://www.nongnu.org/cvs/", "cvs" }, #{link_to "http://darcs.net/", "darcs" }. No shelling out (except when stubbing methods).
+            %li #{workflows_link "Workflows"} for other VCS systems - commands that emulate #{shellscript "bzr push"} instead of #{shellscript "hg push"}, for example.
+            %li Windows support. Honestly, this is primarily just going to be handling file and system paths differently.
+            %li GUI Application on top of #{blue_amp}. Think about that - the one app would support all major VCSs. Cool, eh?
+          %h2 Who works on #{blue_amp}?
+          %p Here's a list of all our contributors, sorted by number of commits:
+          %ul.contributor-list
+            - commit_count.each do |user, commits|
+              %li
+                %span{:style => "width:80px;"}= commits.to_s
+                %span{:style => "width:400px;"}= user
+    = render("include/_footer.haml")

data/site/src/contribute/style.haml

@@ -0,0 +1,297 @@
+!!! 1.1
+%html{ :xmlns => "http://www.w3.org/1999/xhtml" }
+  %head
+    %meta{ :content => "text/html; charset=UTF-8", "http-equiv" => "Content-Type" }
+    %title
+      Amp | Version Control Revolution | Contribute
+    = stylesheets :reset, :amp, :all_themes
+    = javascripts "jquery-1.3.2.min.js", "jquery.cookie.js"
+  %body.oneColFixCtr
+    = render("include/_header.haml", :selected => "contribute")
+    .infopage#container
+      .body-width
+        .floatleft{ :style => "width:90%; padding:8px 0em 6px; margin-left:5%;"}
+          %h2 Style Guidelines
+          %p
+            If you want to contribute to #{blue_amp}, we'd love for you to stick to these guidelines as best as you can. #{ruby_link} has a very flexible, beautiful syntax, which means it's quite easy to write quite ugly code in it. This is <b>not</b> a guide to idiomatic Ruby. It's not even a guide to good-looking Ruby. It's just how we like our code done. This document is a work in progress, so if you see something missing, let us know. If you submit code, we'll eventually end up reformatting it to this style anyway. So try to use this guide!
+          
+          %h3 Table of Contents
+          %ul.tight
+            %li #{link_to "#general", "General Coding"}
+            %ul.tight
+              %li #{link_to "#multiple-assignment", "Multiple Assignment"}
+              %li #{link_to "#80-columns", "80 Columns"}
+              %li #{link_to "#block-bracing", "Block Bracing"}
+              %li #{link_to "#ternary", "Ternary and &&"}
+              %li #{link_to "#for-in", "for...in"}
+            %li #{link_to "#variables", "Variable Names"}
+            %ul.tight
+              %li #{link_to "#descriptive", "Be Descriptive!"}
+              %li #{link_to "#underscores", "Underscores"}
+            %li #{link_to "#method-defs", "Method Definitions"}
+            %ul.tight
+              %li #{link_to "#parens", "Parentheses"}
+              %li #{link_to "#descriptive-methods", "Descriptive Method Names"}
+              %li #{link_to "#one-liners", "Minimize One-line Methods"}
+              %li #{link_to "#spacing", "Spacing!"}
+              %li #{link_to "#class-methods", "Class (Singleton) Methods"}
+            %li #{link_to "#calling-methods", "Calling Methods"}
+            %ul.tight
+              %li #{link_to "#calling-parens", "Parentheses (Redux)"}
+              %li #{link_to "#options-hashes", "Options Hashes"}
+              
+          %a.anchor{:name => "general"}
+          %h2 General Coding
+          %a.anchor{:name => "multiple-assignment"}
+          %h3 Multiple Assignment
+          %p
+            Assigning more than one variable on one line is awesome. As long as it makes sense. If the variables are not related, or the assignments are complex, then you just made things much more confusing. So if you use multiple assignment, the variables should be related, and the values should be concise.
+          %p <b>Unacceptable:</b>
+          .floatleft.dark.rounded.codeholder
+            :syntaxhighlighter
+              repo, user_msg, command_arg = options[:repo], gets, parse_args(2)
+              val1, val2 = proc { |input| input * input.to_i }, proc { |input| input + input.to_i }
+          %p <b>Acceptable:</b>
+          .floatleft.dark.rounded.codeholder
+            :syntaxhighlighter
+              list, others, queue = [], [], []
+              text, date, user = options[:text], options[:date], options[:user]
+
+          %a.anchor{:name => "80-columns"}
+          %h3 80 Columns. If not, 100 columns.
+          %p Self explanatory. We know our long method names make this difficult at times, and we sympathize. Please keep it skinny.
+          
+          %a.anchor{:name => "block-bracing"}
+          %h3 Block Bracing
+          %p
+            Blocks can use "do...end" or "{ ... }" syntax. Braces are to be used for one-line blocks, do...end for multi-line blocks.
+          %p <b>Unacceptable:</b>
+          .floatleft.dark.rounded.codeholder
+            :syntaxhighlighter
+              list.map { |item|
+                item.to_s
+              }
+              list.map do |item|; item.to_s; end
+          %p <b>Acceptable:</b>
+          .floatleft.dark.rounded.codeholder
+            :syntaxhighlighter
+              list.map {|item| item.to_s}
+              list.map do |item|
+                item.to_s
+              end
+          
+          %a.anchor{:name => "ternary"}
+          %h3 Ternary and &&
+          %p
+            Use ternary when possible. Ruby, sadly, makes a full-out if..else..end block a minimum of 5 lines. So use ternary when you can - it's idiomatic and good to get used to. Also, for short "if X then Y" statements, consider using the && syntax, see below.
+          %p <b>Unacceptable:</b>
+          .floatleft.dark.rounded.codeholder
+            :syntaxhighlighter
+              if index > 10
+                return 5
+              else
+                return 7
+              end
+              if idx
+                x = idx
+              end
+          %p <b>Acceptable:</b>
+          .floatleft.dark.rounded.codeholder
+            :syntaxhighlighter
+              return index > 10 ? 5 : 7
+              idx && x = idx
+          
+          %a.anchor{:name => "for-in"}
+          %h3 Never use for..in.
+          %p
+            The #{shellscript "for x in list"} syntax doesn't fly with us. #{link_to "http://blog.grayproductions.net/articles/the_evils_of_the_for_loop", "It isn't exactly the same as calling #each"}. Plus, you can't use { brace } syntax with the for…in loop. So just use #each.
+          %p <b>Unacceptable:</b>
+          .floatleft.dark.rounded.codeholder
+            :syntaxhighlighter
+              for x in 0..9 do
+                p x
+              end
+          %p <b>Acceptable:</b>
+          .floatleft.dark.rounded.codeholder
+            :syntaxhighlighter
+              0..9.each {|i| p i }
+          
+          %a.anchor{:name => "variables"}
+          %h2 Variable Names
+          %a.anchor{:name => "descriptive"}
+          %h3 Descriptive!
+          %p
+            Variable names must be descriptive. When dealing with complex systems, nothing more will scare off developers than these kind of variables: #{shellscript "ctx"}, #{shellscript "octx"}, #{shellscript "wctx"}. In #{blue_amp}'s source, those variables should be named #{shellscript "changeset"}, #{shellscript "other_changeset"}, #{shellscript "working_changeset"}. Yes, it's so much longer. We don't care. If you use descriptive variable names, anyone reading your code knows what that variable is for.
+          %p <b>Unacceptable:</b>
+          .floatleft.dark.rounded.codeholder
+            :syntaxhighlighter
+              acs = cs.ancestor
+          %p <b>Acceptable:</b>
+          .floatleft.dark.rounded.codeholder
+            :syntaxhighlighter
+              ancestor_changeset = current_changeset.ancestor
+          %a.anchor{:name => "underscores"}
+          %h3 under_scores, not CaMeLcAsE
+          %p
+            If your variable name has two words, and is longer than say, 6 letters, put an underscore between the words. Don't use camelcase.
+          %p <b>Unacceptable:</b>
+          .floatleft.dark.rounded.codeholder
+            :syntaxhighlighter
+              currentRepositoryList = currentRepository.changesets
+          %p <b>Acceptable:</b>
+          .floatleft.dark.rounded.codeholder
+            :syntaxhighlighter
+              current_repository_list = current_repository.changesets
+          
+          %a.anchor{:name => "method-defs"}
+          %h2 Method Definitions
+          %a.anchor{:name => "parens"}
+          %h3 Parentheses!
+          %p
+            When defining a method that takes arguments, include the parentheses around the arguments. If the method has no arguments, do not include an empty set of parentheses.
+          %p <b>Unacceptable:</b>
+          .floatleft.dark.rounded.codeholder
+            :syntaxhighlighter
+              def silly_method message, *args
+                puts msg + args.join("\n")
+              end
+              def empty_method()
+                puts "Empty"
+              end
+          %p <b>Acceptable:</b>
+          .floatleft.dark.rounded.codeholder
+            :syntaxhighlighter
+              def silly_method(message, *args)
+                puts msg + args.join("\n")
+              end
+              def empty_method
+                puts "Empty"
+              end
+          %a.anchor{:name => "descriptive-methods"}
+          %h3 Descriptive Method Names
+          %p
+            The title of a method is like the title of a poem: it should provide insight. Make your method names mean something. Now, we have in some cases very long method names for clarity of those reading our documentation. It is acceptable to provide a nice, shorter alias to the method, after defining it with a descriptive name. 
+          %p Below is a comparison between the #{hg_link} methods (slightly Ruby-tized) to the corresponding #{blue_amp} methods here. They perform the exact same operation.
+          %p <b>Unacceptable:</b>
+          .floatleft.dark.rounded.codeholder
+            :syntaxhighlighter
+              def parents(node)
+              def parentrevs(rev)
+          %p <b>Acceptable:</b>
+          .floatleft.dark.rounded.codeholder
+            :syntaxhighlighter
+              def parents_for_node(id)
+              def parent_indices_for_index(index)
+          
+          %a.anchor{:name => "one-liners"}
+          %h3 Minimize One-line Definitions
+          %p
+            There's a time and a place for everything, and one-line methods have a place. If your method body (between <i>def</i> and <i>end</i>) is already one line, and contains no complex logic, then a one-line method might be acceptable. Otherwise, make it a normal, multiline method.
+          %p <b>Unacceptable:</b>
+          .floatleft.dark.rounded.codeholder
+            :syntaxhighlighter
+              # has 3 separate body lines packed into 1
+              def list_stuff(arg1, arg2); arg3 = arg1 + arg2; puts arg3; puts arg1+arg2; end
+              # one line method body, but it's complex enough to put on its own line
+              def silly_one_liner(arg1); arg1.map {|i| i.nil? ? "" : i.to_s}; end
+          %p <b>Acceptable:</b>
+          .floatleft.dark.rounded.codeholder
+            :syntaxhighlighter
+              def silly_one_liner(arg1)
+                arg1.map {|i| i.nil? ? "" : i.to_s}
+              end
+              # simple enough that one line might work
+              def get_value; self.value; end
+          
+          %a.anchor{:name => "spacing"}
+          %h3 Spacing!
+          %p Spacing in your method definitions is a picky matter, and we'll be the first to admit that our style is pretty arbitrary. If you make a good case for a different spacing style, we'll hear it. But for now: put spaces between arguments, none between method name and the following open-parentheses. For optional arguments, but do put spaces around the equals sign. For "splat" or variable-argument holders, don't put spaces between the * and the variable name.
+          %p <b>Unacceptable:</b>
+          .floatleft.dark.rounded.codeholder
+            :syntaxhighlighter
+              def method_one(arg1,arg2)
+              def method_two (arg1, arg2, * rest)
+              def method_three(arg1, arg2, arg3 = {})
+          %p <b>Acceptable:</b>
+          .floatleft.dark.rounded.codeholder
+            :syntaxhighlighter
+              def method_one(arg1, arg2)
+              def method_two(arg1, arg2, *rest)
+              def method_three(arg1, arg2, arg3={})
+              
+          %a.anchor{:name => "class-methods"}
+          %h3 Class (Singleton) Methods
+          %p
+            If you are going to be adding methods to a class, don't use #{shellscript "def self.method"}, use the #{shellscript "class << self"} syntax. This helps delineate which sections of the code belong to the class, and which sections are instance methods. Also, if you need to add class-level attr_accessors, the #{shellscript "class << self"} block is the best way to do that.
+          %p <b>Unacceptable:</b>
+          .floatleft.dark.rounded.codeholder
+            :syntaxhighlighter
+              class Silly
+                def self.monkey
+                  puts "monkey"
+                end
+                def instance_method
+                  puts "yarr"
+                end
+              end
+                
+          %p <b>Acceptable:</b>
+          .floatleft.dark.rounded.codeholder
+            :syntaxhighlighter
+              class Silly
+                class << self
+                  def monkey
+                    puts "monkey"
+                  end
+                end
+                def instance_method
+                  puts "yarr"
+                end
+              end
+          %a.anchor{:name => "calling-methods"}
+          %h2 Calling Methods
+          %a.anchor{:name => "calling-parens"}
+          %h3 Parentheses?
+          %p
+            This one's a tricky one. Generally speaking, you don't need to put parentheses around method arguments in Ruby unless you are nesting method calls. (This isn't always true, there are a few exceptions) This has the effect of making some method calls look like statements. However, you can't chain methods off of a no-parentheses method call, and they have some quirks in conditionals. However, for simple, single method calls, <b>we like this technique.</b> The examples should help clear this up.
+          %p <b>Unacceptable:</b>
+          .floatleft.dark.rounded.codeholder
+            :syntaxhighlighter
+              # always use parentheses on calls inside a block or as an argument to a method
+              puts list.map {|item| item.unshift "h"}
+              # You don't need parentheses here. Strip 'em.
+              puts("hi there")
+              # weirdly enough, this is a syntax error. The exist? call needs parentheses.
+              if file.any? && File.exist? file
+          %p <b>Acceptable:</b>
+          .floatleft.dark.rounded.codeholder
+            :syntaxhighlighter
+              puts list.map {|item| item.unshift("h") }
+            
+              STDERR.puts message
+              
+              if File.exist? file
+                input = File.read file
+              end
+              
+              my_repo.commit revisions, files, :text => options[:text]
+          %a.anchor{:name => "options-hashes"}
+          %h3 Options Hashes
+          %p
+            Ruby has a neat way of doing named optional arguments, until Ruby 2.0 comes out: options hashes. If a method takes a hash as its last argument, you don't need to put { curly braces } around the hash argument. These hashes typically take #{link_to "http://www.troubleshooters.com/codecorn/ruby/symbols.htm", "Symbols"} as keys, instead of strings, due to memory savings. There are some methods in #{blue_amp} that can take many, many options, and formatting calls to these methods can be tricky. The general rule is: if your options wrap to another line, put each option on its own line. Here's how it's done:
+          %p <b>Unacceptable:</b>
+          .floatleft.dark.rounded.codeholder
+            :syntaxhighlighter
+              result = repo.commit arg1, arg2, "text" => "hi", "user" => "hello"
+              result = repo.commit arg1, arg2, :text => "hi", :user => "hello", :date => Time.now, 
+                                               :changeset_base => repo[arg1.to_i], :ancestor => some_other_changeset
+          %p <b>Acceptable:</b>
+          .floatleft.dark.rounded.codeholder
+            :syntaxhighlighter
+              result = repo.commit arg1, arg2, :text => "hi", :user => "hello"
+              result = repo.commit arg1, arg2, :text => "hi", 
+                                               :user => "hello", 
+                                               :date => Time.now, 
+                                               :changeset_base => repo[arg1.to_i], 
+                                               :ancestor => some_other_changeset
+    = render("include/_footer.haml")