1UnboundedSentience

def max_contig(array, k)
  max_len = 0
  sliding_window = []
  window_start = 0
  potential_len = 0
  array.each_index do |idx|
    p "#{idx}  #{sliding_window[0]}---#{sliding_window[-1]}"
    potential_len += 1
    if array[idx] == 0
      sliding_window << idx

1UnboundedSentience

each card has attribute

controller.launch
input:
output: calls greeting

view.display_greeting
input: a greeting as a string
output: printing greeting to screen as a string

1UnboundedSentience

Messages are the foundation of OO, but classes are the most visible org structure.  You must decide what your classes are, how many, behavior, how much they know about other classes, how much they expose.  Group methods into classes.  How you decide will forever influence how you think of your application.  

Good princpiple is to allow for "easy changes": meaning 
-changes have no side effects
-small changes in req require small change sin code
-code easy to reuse

TRUE - transparent, reasonable, useable, exemplary - 

If something has both data and behavior (the gears on a bike have chainrigs, cogs, ratios) there should be a separate class for it, assuming modelling wheel size vs distance travelled is important.