2018-1-9 Meeting notes

Date

09 Jan 2018

7am PST / 4pm CET

Meeting Link

Note we're using Zoom now:

Join from PC, Mac, Linux, iOS or Android: https://zoom.us/j/737202874

Or iPhone one-tap :
US: +16699006833,,737202874# or +14086380968,,737202874#
Or Telephone:
Dial(for higher quality, dial a number based on your current location):
US: +1 669 900 6833 or +1 408 638 0968 or +1 646 876 9923
Meeting ID: 737 202 874
International numbers available: https://zoom.us/zoomconference?m=F0kj5u6u0wFxr7Xfz5NKZxl0xyLhuTPF

Attendees

• Nikodem
• Lukasz
• Klaudia
• Mateusz

Goals

• review last action items - epics are entered, they need to be groomed and prioritized
• Questions on Functional e2e testing?
• feature-based dependencies

Discussion items

Notes

Equals and hashcode

• equals and hashcode are important!
• effects etags - hashcode
  • basic spring implementation uses the hashcode function to determine/compare on etag
  • when getting a user's programs, (Set<ProgramDTO>), the id wasn't included and so
  • EqualsAndHashCode(callsSuper  = false) - can be a problem in DTOs
    • we should likely change all DTOs to callSuper=true on Equals and hash code generation
  • Next steps: to experiment and report back to tech comm how it went

Fluent builder pattern check-in

• Point of using a fluent interface with a builder pattern is to make our tests more readable and maintain
• pattern has been adopted widely
• concerns mentioned:
  • Services often use a fluent builder pattern, but the builder object IS the returned object - and doesn't return an instantiated class
  • UI often returns Javascript classes, rather than plain javascript objects - there isn't clear guideance about which style is preferable 
• Action Item: audit code-base and find if we're consistent and more importantly which ones are the successful ones

Feature based dependencies

Problem:  Microservices however there are hard dependencies between some services - in general we want each service to be independent. (could use some cleanup).  Features (from UI/API to database) - we want to use those or re-use those independent of other services / features.

Scope:  end state is that ideally most services are fully independent, however not all hard dependencies need to be mitigated.

• Services that depend on Reference Data should expect a hard dependency
• From others to one another, we'd like to remove hard dependencies.

Example: If we have Requisition service and Stock Management service - non hard dependency is allowing one or the other service to not be launched:

• Requisition:  the requisition workflow, from grid, to initialization through to final approval all works.  (Requisition, Template, status changes - comments, etc)
• Stock Mgmt: is creating a stock ledger - stock cards.  Daily stock on hand changes.

Goal: is to  allow for features to turn on/off based on if a Service is available.

Solutions:

• Message-oriented solution
  • no services actually know about one another
  • I as a service publish messages out into the ether, and those that are interested are subscribed to those messages and act based on them
  • Common pitfall is that message format tends to lead to hard dependencies
• Feature-based / flags (lack of a better word)
  • re-uses / leverages RESTful HTTP approach (favored API re-use)
  • we want to make features turn on / off, and we do that by detecting the deployments intent - a Service is available if it was in the deployment descriptor (docker-compose)
  • we need to spike on how to:
    
    • read the docker-compose (docker-compose config --services) and create a feature flag based off services deployed
    • we need to publish (consul KV) those flag statuses and consume those in our services (constantly checking? No, config doesn't change.  We want on startup - onetime)
    • Requisition to Stock Mgmt is a good first step to implement (would spur the discussion about which "features" turn off)
      • all stock mgmt fields including reasons for losses and adjustments

Action Items

• Chongsun Ahn (Unlicensed) to try equals and hashcode experiment and report back to next tech comm how it went
• Nick Reid (Deactivated) audit code-base and find if we're consistent and more importantly which ones are the successful ones
• Josh Zamor to write-up feature based dependency spike
• Brandon Bowersox-Johnson to prod the leader to discuss how to untangle Req to SM with feature based flags