014: The Life of a File

Evan Czaplicki's talk The Life of a File.Richard Feldman's Frontend Masters Elm coursesExplore many different data modeling optionsMake Impossible States Impossible Elm Radio episodeWait until you feel the pain vs create abstractions before you need themDoes the code quality metric of line count apply in Elm since there's no spooky action at a distanceAim for loose coupling, high cohesionLocalized reasoningCore mechanics of Elm modules(Organize) Grouping functions values types(Hide) You can hide some of those things. Allows encapsulation, shielding from breaking changes, avoiding coupling.Create modules around domain conceptsUse ubiquitous languageGiant update functionsYou can think of the update function as a delegator - get things to the right place rather than doing the work itselfelm-reviewTCC (test && commit || revert)What are you gaining from extracting a module?Protecting invariantsHiding internalsDecouplingTDD helps drive module design.Experiment, but review your experiments before they become deeply ingrained.Pain in code is for sending a message.Technical debt isn't about "clean code". It's abstractions that serve what the code is doing. Abstractions are inherently expensive and a type of tech debt if they don't serve a purpose for your specific needs.Be proactive - immediately as soon as there is a clear way to make code better (not perfect, small improvement) - do itRelentless, Tiny Habitselm-test Elm Radio episodeTesting is helpful for identifying modules - see keystone testing habit blog postProperty based testing is a sign that something is a module - it has a clear property, which means you want to protect the internalsIt's okay to get it wrong, just don't get it all wrong up front with premature abstractions.