ruby.fundamental

Fundamental programming with ruby examples

This is repo keeps examples with description modern principles, patterns.

Web docs:

• Web docs

Translations:

• Chinese

Content:

• Ruby Gotchas
  • Ruby can be surprising!
  • Don't quote me on this, but ....
  • It's twue! It's twue!
  • Hang him in effigy (String him up, symbolically)
  • String... or nothing!
  • Constants Aren't
  • Some are more equal than others
  • === != ==!
  • and != &&
  • or != ||
  • Don't be so sensitive!
  • 'Ang onto yer @!
  • Look out, it’s an @@!
  • With init(ialize) or without it
  • Superman vs. the Invisible Man
  • When will it end? (Or start?)
  • getting_any?
  • (Un)Def Leppard
  • Freeze (Ar)ray
  • 1 is 1 ... and ever more shall be so!
  • (to! || ! to!) == ?
  • An Array of New Gotchas
  • Making a Hash of it
  • Rescue Me, Throw a Line, I'll Try to Catch It!
  • to_s vs to_str
  • Need to coordinate method_missing and respond_to_missing?
  • Rescue from a StandardError, not an Exception
  • Private data isn’t really, and not at all class methods
  • Instance_eval with access to outside scope
  • Diffs in lambda/proc/block/method
  • Braces vs. do-end (TL;DR: braces high precedence, do-end low)
  • Variable hoisting in Ruby
  • Private methods are accessible by the instance, not the whole class
  • Class Foo::Bar, defined outside Module Foo, won’t see inside Foo
• Meta Programming
  • Dynamic dispatch
  • Dynamic method
  • Ghost methods
  • Dynamic proxies
  • Blank slate
  • Kernel method
  • Flattening the scope
  • Context probe
  • Class eval
  • Class macros
  • Around alias
  • Hook methods
  • Class extension mixin
  • Module namespace interpolation
• Functional Programming
  • Pure Functions
  • Lambda
  • Closures
  • Partial Application and Currying
• Threads
  • Green threads
  • GIL - Global Interpreter Lock
  • Mutex - Mutual Execution
  • Fibers
  • Rails - Thread-safety in the framework
• Solid principles
  • SRP - Single responsibility principle
  • OCP - Open/closed principle
  • LSP - Liskov substitution principle
  • ISP - Interface segregation principle
  • DIP - Dependency inversion principle
• Design patterns
  • Creational pattern
    • Abstract factory pattern
    • Builder pattern
    • Factory pattern
    • Prototype pattern
    • Singleton pattern
  • Structural pattern
    • Adapter pattern
    • Composite pattern
    • Decorator pattern
    • Facade pattern
    • Flyweight pattern
    • Proxy pattern
  • Behavioral pattern
    • Chain of responsibility pattern
    • Command pattern
    • Interpreter pattern
    • Iterator pattern
    • Mediator pattern
    • Memento pattern
    • Observer pattern
    • State pattern
    • Strategy pattern
    • Template method pattern
    • Visitor pattern
• Data Structures
  • Basic axioms of data structures
  • Big O notation
  • Implementation
    • Stack
    • Queue
    • Deque
    • Singly Linked List
    • Double Linked List
    • Ordered List
    • Hash Table
    • Binary Tree
    • Binary Search Tree
    • B Tree
    • Binary Heap
• Algorithms
  • Sorting
    • Bubble sort
    • Insertion sort
    • Selection sort
    • Shell sort
    • Heap sort
    • Merge sort
    • Quick sort
  • Searching
    • Binary search
    • Khuth-Morris-Pratt search
• Interview questions

Ruby Gotchas

Unusual behavior of the ruby - a small details that hide from our sight for hours of hardcore debugging.

by Dave Aronson

Meta Programming

Metaprogramming is the writing of computer programs that write or manipulate other programs (or themselves) as their data, or that do part of the work at compile time that would otherwise be done at runtime. In many cases, this allows programmers to get more done in the same amount of time as they would take to write all the code manually, or it gives programs greater flexibility to efficiently handle new situations without recompilation. Or, more simply put: Metaprogramming is writing code that writes code during runtime to make your life easier.

Functional Programming

Using a language in a functional style implies you have access to a few key features:

• Immutable values: once a “variable” is set, it cannot be changed. In Ruby, this means you effectively have to treat variables like constants.
• No side-effects: when passed a given value, a function must always return the same result. This goes hand in hand with having immutable values; a function can never take a value and change it, as this would be causing a side-effect that is tangential to returning a result.
• Higher-order functions: these are functions that allow functions as arguments, or use functions as the return value. This is, arguably, one of the most critical features of any functional language.
• Currying: enabled by higher-order functions, currying is transforming a function that takes multiple arguments into a function that takes one argument. This goes hand in hand with partial function application, which is transforming a multi-argument func