Skip to content

Instantly share code, notes, and snippets.

View rgkobashi's full-sized avatar

Rogelio Mtz. Kobashi rgkobashi

9 followers · 11 following
  • Tokyo
View GitHub Profile
@rgkobashi
rgkobashi / Clean Code - Advanced TDD - Video Series Summary.md
Created May 29, 2020 08:27
Personal notes/summary of Clean Code Component Design Video Series by Uncle Bob

Advanced TDD (Episode 19.1)

  • Laws:
    1. Dont write any PROD code until you have a failing unit test
    2. Stop writing the test as soon as it fails (including compiling errors)
    3. Stop writing PROD code as soon as the test passes
  • Cycle:
    1. Red
    2. Green
    3. Refactor
  • Write degenerate tests first
@rgkobashi
rgkobashi / Clean Code - Component Design - Video Series Summary.md
Created March 4, 2020 05:22
Personal notes/summary of Clean Code Component Design Video Series by Uncle Bob

SOLID Components (Episode 15)

  • Differences beetween libraries and frameworks
    • Application calls subroutines libraries
    • Framework calls application
  • Component: independant deployable library
  • When designing components is important to identify actors in order to split responsibilities
  • When describing behavior modules avoid saying low level words, instead use abstractions
  • Good episode in how to design modules

Component Cohesion (Episode 16)

@rgkobashi
rgkobashi / Clean Code - SOLID Principles - Video Series Summary.md
Created February 19, 2020 08:20
Personal notes/summary of Clean Code SOLID Principles Video Series by Uncle Bob

Foundations of the SOLID principles (Episode 8)

  • Design smells:
    • Immobility
    • Viscosity: how easy is to add design-preserving code to a system
    • Needles complexity
  • Dependency management principles:
    • SOLID
    • Component cohesion principles
    • Component coupling principles
@rgkobashi
rgkobashi / Clean Code - Fundamentals - Video Series Summary.md
Created February 19, 2020 08:18
Personal notes/summary of Clean Code Fundamentals Video Series by Uncle Bob

Code smells (Episode 1)

  • Rigidity: difficult to make changes (small change causes a cascade of subsequent changes)
  • Fragility: a single change causes breaks in many places
  • Inseparability: no reusability
  • Opacity: code is hard to understand

Naming (Episode 2)

  • Make sure you communicate intent
  • Avoid disinformation
  • Use pronounceable names
@rgkobashi
rgkobashi / Appearance.swift
Created September 30, 2018 07:53
Hide/Show status bar iOS Swift
// The methods of Appearance.StatusBar can be used to hide and show the status bar on iOS.
// As mention in other places, this is more like hack than a solution. I personally don't like it.
// However if on your application you are making use of navigationBar or similar components,
// hidding the statusBar on the right way (overriding `prefersStatusBarHidden`) will mess with your constraints.
// For more details please refer to this answer and its comments: https://stackoverflow.com/a/44066303/8483739
struct Appearance {
private init() {}
}
@rgkobashi
rgkobashi / .swiftlint.yml
Last active February 25, 2020 10:54
This will disable every single rule on SwiftLint. This is useful to start using SwiftLint on large projects (like `the incremental code stylist` described on `Watch Your Language!` talk). Since *all existing rules* are listed here, you can gradually enable the ones that you need.
# Listing every single rule as v0.38.2 with the purpose of linting following `incremental code stylist`.
disabled_rules: # rules enabled by default, comment to enable
- block_based_kvo
- class_delegate_protocol
- closing_brace
- closure_parameter_position
- colon
- comma
- compiler_protocol_init