alvinncx

# Pretty simple challenge. The key is to loop through the string to keep finding instances of legal chucks and remove them.
# Chucks are made of itself so you can just keep removing the simplest chunks
class Line
  attr_reader :temp

  def initialize(raw)
    @raw = raw
    @temp = raw

    parse

alvinncx

# By far the most tedious puzzle to get the 2nd ⭐️
# Display class -> this is where most of the logic happens. Use different combinations of digit segments to determine
# the correct mapping

class Digit
  attr_accessor :segments, :length

  def initialize(raw)
    @raw = raw
    @segments = raw.split('') 

alvinncx

export const function1 = () => {
  return 'awesome'
}

export const function2 = () => {
  return 'not so awesome'
}

alvinncx

Sprint is a cycle lasts 4 weeks

• Don't like the name, not sustainable
• 2 weeks more common
• No gap or delay between sprints

Stages

Plan

Sprint goal

• Valuable, clear, realistic, won't change

alvinncx

Principles in Refactoring

Purpose of refactoring

• Make the software easier to understand
• Does not change observable behavior

Difficult to change

• Programs that are hard to read are hard to modify.
• Programs that have duplicated logic are hard to modify.
• Programs that require additional behavior that requires you to change running code are hard to modify.

alvinncx

class Price 
  def price_code; end
  def charge; end
  def frequent_renter_points
    1
  end
  
  class Childrens
    def price_code; Movie::CHILDRENS; end
    def charge(days_rented)

alvinncx

Design in construction

• Software’s Primary Technical Imperative is managing complexity. This is greatly aided by a design focus on simplicity.
• Simplicity is achieved in two general ways: minimizing the amount of essential complexity that anyone’s brain has to deal with at any one time, and keeping accidental complexity from proliferating needlessly.
• Design is heuristic. Dogmatic adherence to any single methodology hurts cre- ativity and hurts your programs.

Information Hiding

• Foundation of OOP and structured design
• Thinking in objects vs thinking in information hiding
  • Hiding abstracts complexity and delays lock in; thinking in OOP locks you into smaller set of decisions
• e.g. Should something be declared as a new class

alvinncx

My thoughts on Sandi Metz's presentation on better OOP Design

Youtube Link

How to write better Object Oriented code. The central claim is that OO is not a problem, but many teams are not utilising the features of OO to design better code. Her other point is also that design becomes more important late stage as code bases becomes bigger.

Takeaway points

• Premature design is bad. Does not really add value. However when design is required later, it is too late and most people don't know how to do it properly.
• Code that is properly abstracted should be easier to change than complex routines. However, wrongly abstracted code can also make it as difficult at complex code.

alvinncx

If you happen to be reading the 20th anniversary edition of The Mythical Man-month, you can skip right to Chapter 18 for an outline of the entire book. Why this was added later is anyone's guess...

Chapter 2

• Adding more people into a project that is overdue, makes it even later.
• Throwing people at project without consideration of training, reallocation and communication is a disaster.

• I used to apply the naive way of calculating time for a project. I was often wrong.
• Eventually I found that using 4x the time of the initial estimates works well.
• This is based on the assumption of degrees of freedom. If only developer is estimating, it is 2x original estimate. If requirements are incertain, then add additional 2x. This amounts to 4x.
• Time for administration and ramp-up is often underestimated.

alvinncx

import Browser
import Html exposing (..)
import Html.Attributes exposing (..)
import Html.Events exposing (..)

-- Main
main =
  Browser.sandbox {init = init, update = update, view = view}

-- Model