Pragmatic Programmer: Chapter 3

Learning basic tools to feel comfortable constructing your own toolkit

Power of plain text:

• Insurance against obsolescence 
  • Self describing data carries context with data. Look at application.yml to see keys and their meaning. Many elements describe their purpose with their name.
• Leverage
  • grep/ag/ruby/python/perl/bash/sh
  • Many tools exist to help parse and search text files. 
  • No need to invest time fixing solved problems.
• Easier testing 
  • Simple to generate test data

Shell games

Helpful tools and snippets for every day usage.

• jq - echo '{...}' | jq is a helpful shorthand for pretty printing json  
• Git alias for seeing branch history git for-each-ref --sort=committerdate refs/heads/
• ag $1 -l | wc for quickly seeing occurrences of a pattern in project
• Search and replace with ag: ag -l $1 | xargs perl -pi.bak -e "s/$1/$2/g"
• Switch webservers between shotgun & unicorn quickly during development:
  • https://gist.github.com/dsilfen-handy/bc0558bd4cb1ad6b263024a6e708a7b2

Power editing

• Learning one editor to whole completion and having your own configuration to make the evacuation of code from your mind  seamless
• Learning one editor well should lead to less work creating the end result. 
• It will help you manipulate plain text in new ways that save time and mental cycles
• "A feature such as syntax highlighting may sound like a frivolous extra" - this must be an understatement, has anyone here coded productively without syntax highlighting? 

Source code control

Does anyone have any interesting uses of source control?

• Git for dotfiles
• We have made attempts at using /rfcs for proposed changes to our app
• Other worthwhile Implementations of source control?
• Commit and push habits? When do you feel ready for "git commit"

Debugging

• Blame does not fix the problem faster. No matter what created the bug it is still your problem.
• Don't panic
• "That's impossible" is wrong
• Don't address the symptoms, attack the root cause
• Reproduce the bug with a test to prove its existence and test your fixes
• Print statement debugging to show the values in our code at a certain time
  • this can change our codes behavior especially with rspec due to its lazy evaluation features
• Rubber duck with a co-worker or a rubber duck to try and get a new view on the problem
• binding.pry to set breakpoints
• Process of elimination: prove the area of code that is incorrect before jumping to a false conclusion
• Reevaluate truths you hold dear, new knowledge could render false assumptions invalid.
  • Prove old code true again before moving forward.

Once you've fixed the bug, ask yourself what went wrong that allowed that bug to enter the application? What can we do in the future to prevent these bugs?

Debugging Checklist

Is the problem being reported a direct result of the underlying bug, or merely a symptom?

Is the bug really in the compiler? Is it in the OS? Or is it in your code?

If you explained this problem in detail to a coworker, what would you say?

If the suspect code passes its unit tests, are the tests complete enough? What happens if you run the unit test with this data?

Do the conditions that caused this bug exist anywhere else in the system?

Text Manipulation

• Does anyone have any small scripts that they use on a daily basis for text manipulation?

Code Generators

Passive Generators

• Using rails g when possible for applicable use cases
• RubyMine and other IDEs offer templates for common use cases, like rake tasks and new POROs

Active Generators

• ActiveRecord as a sort of code generator
  • Our rails migrations are just code generators for SQL
  • Our where calls are essentially the same thing
  • ActiveRecord appends fields on our models based on the corresponding table definition

Extras

• Interesting read about text searching tools. Ack vs Grep type tools, and a new tool from the rust team called ripgrep.