Profile_bird

Hey there! mariogleichmann is using Twitter.

Twitter is a free service that lets you keep in touch with people through the exchange of quick, frequent answers to one simple question: What's happening? Join today to start receiving mariogleichmann's tweets.

Already using Twitter
from your phone? Click here.

mariogleichmann

  1. In light of actual events: seek loow coupling in the sense of concepts that can be understood and reasoned about independently of each other
  2. Agree DDD: choose Modules that tell the story of the system and contain a cohesive set of concepts
  3. Agree DDD: Modules in domain layer should emerge as meaninful part of the model,telling the story of the domain on a larger scale
  4. FP+1: If a function is pure it's guaranteed isolated from other parts, hence easier 2 change code in 1 place w/o breaking anything unrelated
  5. :_* in Scala: 'treat this sequence as a sequence' o/wise your n items seq will be treated as seq of 1 item (which will be your n item seq)
  6. If u understand Liskov Subst.principle and Design By Contract esp.under inheritance, you'll also understand contra- and covariance in #Scala
  7. @tiagofernandez ...s/times become aware of 'thinking in Scala' in terms of using some concepts (traits,implcits,...) when in Java land...;o)
  8. Today it happened:Java compiler complains about missing return statement while i'm staring @ expression + puzzled because 2 attuned to Scala
  9. Would you agree Eric Evans (DDD) about Modules / Packages: cognitive overload is the primary motivation for modularity ... ?
  10. If u start 2 play with nested type declarations in #Scala, be sure to understand Path-Dependend Types, otherwise you'll run into trouble...
  11. Agree DDD on Services: operation names should come from the ubiquitous language. Parameters and results should be domain objects
  12. Agree DDD: changing code changes the model, so programmers are modelers, wether anyone likes it or not ...
  13. Agree DDD: effects of a model can be very sensitive to details which don't always come across UML diagrams - so programming is all design
  14. @stal_m : i'm interested of writing some Scala stuff ... any preferences about a special topic?
  15. Agree Wirfs-Brock about RDD and TDD: 'With a design-test-code-reflect-refactor rhythm, good code emerges alongside well-designed interfaces'
  16. Excellent Article about core of Responsibility-Driven Design (in contrast to structural focussed design strategies) at http://tiny.cc/RgFKK
  17. CleanCodeCampfireRule++:'Our responsibility is to do what we can,learn what we can,improve the solutions and pass them on' Richard P.Feynman
  18. My understanding of TDD: TDD involves short cycles of writing specs that prove the DESIGN, not verifying some code / implementation
  19. Clean code roots:our main task isn't 2 instruct a computer what to do,but rather on explaining to human beings what we want it to do.D.Knuth
  20. Wirfs-Brock on DUF vs. BDUF: Upfront design needn’t be wasteful if you develop a design rhythm that balances thinking, learning and doing