<commit_before>.content.module
  .page-header
    %h1 Basic Ruby

  .row
    .col-lg-8
      %p It's easy to get into the magic of rails and forget that the underlying language, ruby, is also a beautiful thing. Philosophically, ruby and rails share a lot of the same predilections: they both value terse, expressive syntax, they have a strong open source, test-focused community, and they're full of both elegant and scary magic. It's easy to do great things with ruby, but it's also very easy to make a mess. Let's build a basis of clean ruby to prevent trouble down the road.

      .page-header
        %h3 Ruby Core
        %p Take some time to practice with ruby core. There are a million tutorials around to teach you the basics, but once you've experienced the really simple stuff (arrays and hashes and variables and iteration), you'll find that the most important thing to do is to write a lot of ruby, and to get someone more experienced to review that code.
        %p Also, after several years of writing ruby programs, I still find myself opening the official ruby docs for core classes to find the right method to turn my code into something simple and capable.

        = exercise_block_for "ruby", "docs" do |e|
          = e.question "Ruby core has so many more methods than you'll ever keep in your head. That's totally fine, but you need to know how to look up and use those functions. Use the ruby docs to find the docs for the String class. There's a method that lets you substitute a bunch of characters for a corresponding set of characters (it's not gsub). Find that method and use it in a code sample"

        = exercise_block_for "ruby", "ruby_core" do |e|
          = e.question "Let's write a ruby program so that we can play with the code. Do the #{exercise_link 'dino_catalog'} exercise."
          = e.question "For practice, try the first few ruby Exercism problems, and make sure to nitpick other people's code."

      .page-header
        %h3 Stylish (and Sane) Ruby
        %p Since ruby is dynamically typed and also extremely terse, it's easy to get into trouble after writing relatively little code. It's not so much that ruby gives you a gun to shoot yourself with, it also insists on pointing that gun at your foot. There are some simple heuristics we've learned to use over time that make it possible to continue working with your code for a while, not to mention working in a large team. Just remember, they have guns too.

        %p The first, most obvious thing is to standardize on a single way of writing ruby. Because the syntax is so flexible, there are typically many ways to write a given program. Instead, we should usually follow the conventions of the popular Ruby Style Guide. That said, remember that clarity is always key, so if a particular piece of code is more comprehensible, it can make sense to break the rules.

        = exercise_block_for "ruby", "style_guide" do |e|
          = e.question "Fix the code example in the #{exercise_link 'style_guide'} exercise so that it conforms to the Ruby style guide."
          = e.question "Go back and make sure that your dino_catalog code conforms to the style guide. Bonus points if it did already."

        %p Another common pattern that is both common and totally unnecessary is called Arrowhead Programming. this is pretty simple to diagnose. If a method indents more than maybe two levels, it probably needs to be refactored. Method calls are cheap relative to other resources, so reorganizing and refactoring your code to avoid this particular problem is well worth it.

        %p Try this talk by <a href='https://www.youtube.com/watch?v=npOGOmkxuio'><NAME></a> for some discussion of this and the next few ideas.

        = exercise_block_for "ruby", "arrowhead" do |e|
          = e.question "Look at the code in the #{exercise_link 'arrowhead'} exercise. It currently fails to put error conditions near their conditions. Refactor it so that it isn't terrible anymore."
          = e.question "Go fix your dino_catalog code so that it conforms to this rule."

        %p The next rule turns out to be related to the previous one: you should write short methods, and short lines of code. Games like code golf are lots of fun, but if you check abstruse one-liners into the production codebase you're mostly just a jerk. A decent rule of thumb is to have no more than five lines of code in a method, and to keep your lines of code under eighty characters. That said, it's still possible to write a lot of terrible code in eighty characters, so consider rewriting any line whose meaning is not entirely apparent.

        %p Also by <NAME> (sense a theme?), the book Practical Object Oriented Design in Ruby. There are copies in the library, take one and read at least the first several chapters to get an idea here. Then, snag a copy of Confident Ruby for some more ideas.

        = exercise_block_for "ruby", "short_methods" do |e|
          = e.question "We're going to continue rocking these exercises. The #{exercise_link 'short_methods'} exercise seems apropos here."
          = e.question "Your dino_catalog code is probably still offensive. Fix that."

        %p Even with short lines of code, it's not always possible to understand all code at a glance, so we put a lot of focus on using meaningful variable and method names. Ideally, someone reading your code should not even need to look at the body of a method to know what it does; the name should stand alone sufficiently to describe it. Similarly, variable names serve either to enlighten or confuse others as they read your code.

        %p Naming is always going to be hard (it's actually stated as one of the hard problems of computer science), but this <a href='http://www.rubytapas.com/episodes/87-Naming-Head-Count'>Tapas</a> does a good job of walking you through some ideas around naming.<commit_msg>fix exercise links for moved exercises<commit_after>.content.module
  .page-header
    %h1 Basic Ruby

  .row
    .col-lg-8
      %p It's easy to get into the magic of rails and forget that the underlying language, ruby, is also a beautiful thing. Philosophically, ruby and rails share a lot of the same predilections: they both value terse, expressive syntax, they have a strong open source, test-focused community, and they're full of both elegant and scary magic. It's easy to do great things with ruby, but it's also very easy to make a mess. Let's build a basis of clean ruby to prevent trouble down the road.

      .page-header
        %h3 Ruby Core
        %p Take some time to practice with ruby core. There are a million tutorials around to teach you the basics, but once you've experienced the really simple stuff (arrays and hashes and variables and iteration), you'll find that the most important thing to do is to write a lot of ruby, and to get someone more experienced to review that code.
        %p Also, after several years of writing ruby programs, I still find myself opening the official ruby docs for core classes to find the right method to turn my code into something simple and capable.

        = exercise_block_for "ruby", "docs" do |e|
          = e.question "Ruby core has so many more methods than you'll ever keep in your head. That's totally fine, but you need to know how to look up and use those functions. Use the ruby docs to find the docs for the String class. There's a method that lets you substitute a bunch of characters for a corresponding set of characters (it's not gsub). Find that method and use it in a code sample"

        = exercise_block_for "ruby", "ruby_core" do |e|
          = e.question "Let's write a ruby program so that we can play with the code. Do the #{exercise_link 'dino_catalog'} exercise."
          = e.question "For practice, try the first few ruby Exercism problems, and make sure to nitpick other people's code."

      .page-header
        %h3 Stylish (and Sane) Ruby
        %p Since ruby is dynamically typed and also extremely terse, it's easy to get into trouble after writing relatively little code. It's not so much that ruby gives you a gun to shoot yourself with, it also insists on pointing that gun at your foot. There are some simple heuristics we've learned to use over time that make it possible to continue working with your code for a while, not to mention working in a large team. Just remember, they have guns too.

        %p The first, most obvious thing is to standardize on a single way of writing ruby. Because the syntax is so flexible, there are typically many ways to write a given program. Instead, we should usually follow the conventions of the popular Ruby Style Guide. That said, remember that clarity is always key, so if a particular piece of code is more comprehensible, it can make sense to break the rules.

        = exercise_block_for "ruby", "triangle_facts" do |e|
          = e.question "Fix the code example in the #{exercise_link 'triangle_facts'} exercise so that it conforms to the Ruby style guide."
          = e.question "Go back and make sure that your dino_catalog code conforms to the style guide. Bonus points if it did already."

        %p Another common pattern that is both common and totally unnecessary is called Arrowhead Programming. this is pretty simple to diagnose. If a method indents more than maybe two levels, it probably needs to be refactored. Method calls are cheap relative to other resources, so reorganizing and refactoring your code to avoid this particular problem is well worth it.

        %p Try this talk by <a href='https://www.youtube.com/watch?v=npOGOmkxuio'><NAME></a> for some discussion of this and the next few ideas.

        = exercise_block_for "ruby", "arrowhead" do |e|
          = e.question "Look at the code in the #{exercise_link 'arrowhead'} exercise. It currently fails to put error conditions near their conditions. Refactor it so that it isn't terrible anymore."
          = e.question "Go fix your dino_catalog code so that it conforms to this rule."

        %p The next rule turns out to be related to the previous one: you should write short methods, and short lines of code. Games like code golf are lots of fun, but if you check abstruse one-liners into the production codebase you're mostly just a jerk. A decent rule of thumb is to have no more than five lines of code in a method, and to keep your lines of code under eighty characters. That said, it's still possible to write a lot of terrible code in eighty characters, so consider rewriting any line whose meaning is not entirely apparent.

        %p Also by <NAME> (sense a theme?), the book Practical Object Oriented Design in Ruby. There are copies in the library, take one and read at least the first several chapters to get an idea here. Then, snag a copy of Confident Ruby for some more ideas.

        = exercise_block_for "ruby", "robot_name" do |e|
          = e.question "We're going to continue rocking these exercises. The #{exercise_link 'robot_name'} exercise seems apropos here."
          = e.question "Your dino_catalog code is probably still offensive. Fix that."

        %p Even with short lines of code, it's not always possible to understand all code at a glance, so we put a lot of focus on using meaningful variable and method names. Ideally, someone reading your code should not even need to look at the body of a method to know what it does; the name should stand alone sufficiently to describe it. Similarly, variable names serve either to enlighten or confuse others as they read your code.

        %p Naming is always going to be hard (it's actually stated as one of the hard problems of computer science), but this <a href='http://www.rubytapas.com/episodes/87-Naming-Head-Count'>Tapas</a> does a good job of walking you through some ideas around naming.
{'fraction_non_alphanumeric': 0.049276098552197105, 'fraction_numerical': 0.001016002032004064, 'mean_word_length': 3.5222052067381315, 'pattern_counts': {'":': 0, '<': 15, '<?xml version=': 0, '>': 15, 'https://': 2, 'lorem ipsum': 0, 'www.': 4, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '1188095', 'n_tokens_mistral': 2997, 'n_tokens_neox': 2810, 'n_words': 1866}