{"id":15463329,"url":"https://github.com/cored/lunch-n-learn","last_synced_at":"2026-03-02T04:31:42.085Z","repository":{"id":66523358,"uuid":"85700876","full_name":"cored/lunch-n-learn","owner":"cored","description":"Talks, articles, papers that I watch or read during lunch time","archived":false,"fork":false,"pushed_at":"2017-04-05T17:40:38.000Z","size":10,"stargazers_count":0,"open_issues_count":0,"forks_count":0,"subscribers_count":1,"default_branch":"master","last_synced_at":"2025-02-21T12:35:13.009Z","etag":null,"topics":["design-principles","programing-languages","tech-talks"],"latest_commit_sha":null,"homepage":"","language":null,"has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":null,"status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/cored.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":null,"code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2017-03-21T12:47:17.000Z","updated_at":"2018-03-01T14:19:09.000Z","dependencies_parsed_at":"2023-02-28T01:15:37.618Z","dependency_job_id":null,"html_url":"https://github.com/cored/lunch-n-learn","commit_stats":{"total_commits":12,"total_committers":1,"mean_commits":12.0,"dds":0.0,"last_synced_commit":"04606e579cc675834b181931060011ac6303c5a2"},"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"purl":"pkg:github/cored/lunch-n-learn","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/cored%2Flunch-n-learn","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/cored%2Flunch-n-learn/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/cored%2Flunch-n-learn/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/cored%2Flunch-n-learn/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/cored","download_url":"https://codeload.github.com/cored/lunch-n-learn/tar.gz/refs/heads/master","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/cored%2Flunch-n-learn/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":29992302,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-03-02T01:47:34.672Z","status":"online","status_checked_at":"2026-03-02T02:00:07.342Z","response_time":60,"last_error":null,"robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":true,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["design-principles","programing-languages","tech-talks"],"created_at":"2024-10-02T00:20:27.102Z","updated_at":"2026-03-02T04:31:42.069Z","avatar_url":"https://github.com/cored.png","language":null,"funding_links":[],"categories":[],"sub_categories":[],"readme":"# Lunch-n-Learn\n\nTalks, articles, papers that I watch or read during lunch time\n\n### Talks\n\n* [The insufficiency of good design by Sarah Mei](https://www.youtube.com/watch?v=UgrVdHYEZGg)\n  * [Conway's Law](https://en.wikipedia.org/wiki/Conway's_law)\n  * Good communication produces good code\n  * Decoding smelly code\n    * Hidden silos\n    * Every piece of bad code is trying to say something\n  * [Pair Programming](https://en.wikipedia.org/wiki/Pair_programming)\n  * Create opportunities for informal communication\n\n* [SOLID Object Oriented Design by Sandi Metz](https://www.youtube.com/watch?v=v-2yFMzxqwU)\n  * [SOLID](https://en.wikipedia.org/wiki/SOLID_(object-oriented_design))\n  * Rigid - Every change causes a cascade of changes\n  * Fragile - Distant and unrelated changes with every other change\n  * Immobile - You can't reuse anything\n  * [Design Stamina Hypothesis](https://www.martinfowler.com/bliki/DesignStaminaHypothesis.html)\n  * Only mock classes that you own\n  * Don't mock/stub the object under test\n  * The fact that there's a need to refactor doesn't mean you should\n  * Don't be attached to your first idea\n    * Embrace the code friction\n    * If testing seems hard there's a problem with the design\n    * TDD will punish you if you don't understand about design\n  * [TDD Rules](http://agileinaflash.blogspot.com/2009/03/unclebobs-three-rules-of-tdd.html)\n    * Refactor\n      * Is the code [DRY](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself)?\n      * Does it have one responsibility?\n      * Does everything change at the same rate?\n      * Does it depends that change less often than the unit itself?\n  * Code Smells\n    * Describing something using \"and\" implies that it does two different\n      things\n    * Describing something using \"or\" implies that it does two different and\n      unrelated things\n    * As soon as you feel resistant with arguments order that's a [data clump](https://en.wikipedia.org/wiki/Data_Clump_(Code_Smell))\n      use a hash or value object\n  * When testing - if it's going to change on production inject if not stub\n  * Refactor not because you know which is the abstraction but because you want\n    to find it.\n  * [class_eval](https://www.jimmycuadra.com/posts/metaprogramming-ruby-class-eval-and-instance-eval)\n  * It is better to depend on things that doesn't change often\n  * TDD is not enough\n  * DRY is not enough\n  * Design because you expect your application to succeed\n\n* [Less - The path to better design by Sandi Metz](https://vimeo.com/26330100)\n  * What is design?\n    * Not something establish by an architect but something you evolve through\n      several iterations\n  * Code needs to - work today, be able to change forever\n  * Design purpose\n    * Reduce the cost of change\n  * [Design description](https://content.pivotal.io/blog/solid-object-oriented-design-sandi-metz)\n    * Easily composable\n    * Highly cohesive\n    * Loosely coupled\n    * Context independent\n  * TRUE\n    * Transparent - Consequence of change should be obvious\n    * Reasonable - Cost of adding a new feature is proportional to it's value\n    * Usable - If you write the code; you should be able to use it\n    * Exemplary - More code like this should be good for your application\n  * Knowledge is coupling\n    * Create dependencies\n    * Unstable dependencies increases risk\n    * Try to always loose coupling\n    * Uncertainty should be your guide\n\n* [Therapeutic Refactoring by Katrina Owens](https://www.youtube.com/watch?v=J4dlF0kcThQ)\n  * Guilt driven development\n    * [Refactoring](https://martinfowler.com/books/refactoring.html)\n  * [Characterization tests](https://en.wikipedia.org/wiki/Characterization_test)\n    * Add test cases to discover what the code do right now\n  * [Replace method with method object](https://sourcemaking.com/refactoring/replace-method-with-method-object)\n    * To isolate the behavior\n    * Rename methods in terms of what the method does\n    * Follow longest lines to do extraction for clarification\n      * Helps you identify a piece of code that does something and give it\n        a name\n  * [Code smells](https://sourcemaking.com/refactoring/smells)\n  * Code junks\n    * Comments\n      * Do not echo the implementation\n      * Do not be wrong or mispell\n    * White spaces\n    * Remove dead code\n    * Needles parenthesis\n    * Explicit default parameters\n    * Unneeded dependencies\n    * Too much hard work - simplify the code at every change\n    * Duplicated tests\n    * Combine all of the above\n\n* [Get a whiff of this by Sandi Metz](https://www.youtube.com/watch?v=PJjHfa5yxlU)\n  * [Code smells](https://sourcemaking.com/refactoring/smells)\n    * Bloaters\n      * [Long method](https://sourcemaking.com/refactoring/smells/long-method)\n      * [Large class](https://sourcemaking.com/refactoring/smells/large-class)\n      * [Data clumps](https://sourcemaking.com/refactoring/smells/data-clumps)\n      * [Long parameter list](https://sourcemaking.com/refactoring/smells/long-parameter-list)\n      * [Primitive obsession](https://sourcemaking.com/refactoring/smells/primitive-obsession)\n    * Tool abusers\n      * [Switch statements](https://sourcemaking.com/refactoring/smells/switch-statements)\n      * [Refused bequest](https://sourcemaking.com/refactoring/smells/refused-bequest)\n      * [Alternative Classes w/ different interfaces](https://sourcemaking.com/refactoring/smells/alternative-classes-with-different-interfaces)\n      * [Temporary field](https://sourcemaking.com/refactoring/smells/temporary-field)\n    * Change preventers\n      * [Divergent change](https://sourcemaking.com/refactoring/smells/divergent-change)\n      * [Shotgun surgery](https://sourcemaking.com/refactoring/smells/shotgun-surgery)\n      * [Parallel inheritance hierarchies](https://sourcemaking.com/refactoring/smells/parallel-inheritance-hierarchies)\n    * Dispensables\n      * [Lazy class](https://sourcemaking.com/refactoring/smells/lazy-class)\n      * [Speculative generality](https://sourcemaking.com/refactoring/smells/speculative-generality)\n      * [Data class](https://sourcemaking.com/refactoring/smells/data-class)\n      * [Duplicated code](https://sourcemaking.com/refactoring/smells/duplicate-code)\n    * Couplers\n      * [Feature envy](https://sourcemaking.com/refactoring/smells/feature-envy)\n      * [Inappropriate intimacy](https://sourcemaking.com/refactoring/smells/inappropriate-intimacy)\n      * [Message chains](https://sourcemaking.com/refactoring/smells/message-chains)\n      * [Middle man](https://sourcemaking.com/refactoring/smells/middle-man)\n  * Every code smell has a refactoring recipe\n\n* [Rampant Emergence: Lessons Learned from 4 Years of Aggressive Change by Neal Ford](https://vimeo.com/75256535)\n  * Emergent design\n    * Finding abstractions and patterns\n    * Last responsible moment - It is safe to defer decisions?\n      * Longer delay; more real data for decision\n    * [Who needs an architect](https://martinfowler.com/ieeeSoftware/whoNeedsArchitect.pdf)\n    * Architecture\n      * Dynamic - Hard to change later\n      * Static - web frameworks, tools. Allow few changes as possible\n      * Product - features\n      * Technical - Static/Dynamic\n    * Traditional architect role\n      * Define long term architecture up front\n    * Agile architecture role\n      * Few architecture elements and make them as flexible as possible\n    * Don't do stupid things\n      * Staff projects inadequately\n      * Ramp up staffing too quickly\n      * Assume good initial velocity on brand new X\n      * Indulge in RDD (Resume Driven Development) - Put every single\n        technology on your codebase\n      * Anything on [Anti Patterns Catalog](http://c2.com/cgi/wiiki?AntiPatternsCatalog)\n    * Be careful of architectural smearing\n      * Produce afferent/efferent coupling between components\n    * Stay in sync with upgrades\n      * Tools, OS, frameworks\n      * Future ported features are hard to refactor\n      * Lingering upgrades == technical debt * 2\n      * Age of codebase by number of components ongoing effort required for\n        stasis\n      * Especially true for \"smeary\" frameworks - Rails does this\n      * Budget early as technical stories/tasks\n    * Keep domain logic DRY\n      * Business rules\n      * Validations\n      * Data rules\n      * Workflow\n    * Functionality must exist across tiers\n    * Green to brown - when a project has some time in development\n      * Every project hits an inflection point\n      * Engineering practices should reflect the change\n      * Add semi-permanent technical debts cards (Why not do refactoring every\n        time someone touches the code?)\n      * Harvesting model for reuse\n      * Switch to emergent design styles\n    * No design\n      * No matter how much you try, requirements evolve chaotically\n      * Bed-rock assumptions become malleable\n    * Prefer dynamic over static\n      * Don't think of the application as an equation\n      * Make rules and policies dynamic\n    * Loose coupling at integrations points\n      * Early integration efforts focused on RPC-style interaction\n      * Great for an equation bu lousy for a process\n      * Resources over remote procedure calls\n      * Choreography over orchestration\n    * Coarse-grained components/services\n      * Continuous delivery\n    * Semantic monitoring\n    * [Consumer driven contracts](http://martinfowler.com/articles/consumerDrivenContracts.html)\n    * For brown field projects\n      * Refactoring and restructuring exercises require increasing effort for\n        the same result\n      * Plan escalating effort towards remedial architecture and design\n      * Trade off for reduced up-front effort\n\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fcored%2Flunch-n-learn","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fcored%2Flunch-n-learn","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fcored%2Flunch-n-learn/lists"}