Building to Last Welcome to Iteration: A weekly podcast about programming, development, and design through the lens of amazing books, chapter-by-chapter On following fashions What are short-lived trends? What will stand the test of time? How to approach hot new techniques: Ask yourself: Does the code feel easier to read and change after refactoring? How did the complexity increase or decrease Did you run into any new issues? John: If you keep changing with the trends “your codebase will be a patchwork of different styles making it very hard to understand or change” there are no silver bullets Surviving the upgrade pace of Rails Gems increase the cost of upgrades (so do NPM modules) 👀 react navigation Don't live on the bleeding edge Owning your stack Own the gems you put in. How do you decide on if a gem is worth including in your library? should you just write some small helpers yourself to accomplish it? Idea of maxing out your current toolbox first Should you use redis? or can you just use another sql table? John: When you pull in dependencies - YOU OWN IT. IT’S YOUR CODE NOW. The value of tests We're a broken record here. one thing to point out is that this lets you release often! You can also work on one part of the app in isolation without having to worry about the rest John: Test suite is like a light in a dark house - give you enough coverage so you know there isn’t a monster lurking Picks: https://www.notion.so/ - How meta - we use Notion to manage this podcast.

A weekly podcast about programming, development, and design through the lens of amazing books, chapter-by-chapter. A System for Growth Dealing with complicated models John: How / Why do they grow? Needs change: John: All the different use cases for a user John: "When you need to implement password recovery, and do not have a clear, single place to put the logic, it will still find its way into your code. It will spread itself across existing classes, usually making those classes harder to read and use.” Example problem: Want to send a welcome email when a user is created via a public form but not when an admin creates a user via a backend interface Fat models == missing classes don't actively look for an AR class, look for new classes to contain new logic A home for interaction specific code Core models should only have the absolute minimum to exist: set of validations to enforce data integrity definitions for associations (belongs_to, has_many) universally useful convenience methods to find or manipulate records (scopes) Core models should NOT have these things: (these things belong in multiple, interaction-specific form models) virtual attributes that don't map 1:1 with db callbacks to fire for a particular screen or use case (i.e. form signup) we want the perks of AR models with AR. solution: inheritance class User::AsSignUp < User validates :password, presence: true, confirmation: true after_create :send_welcome_email private def send_welcome_email; end end John: Note the "AsSignup" pattern - "AsFacebookAuth" Extracting service objects (lol) probably a good indicator of a service object is when you find yourself using class methods. i.e. def self.something John: Didn’t we just move code around? - "what used to be a monolithic blob of intertwined logic is now separated into multiple, loosely coupled components.” Better maintainability, testing, and reuse. Organizing large codebases with namespaces class Invoice < ActiveRecord::Base has_many :items end class Item < ActiveRecord::Base belongs_to:invoice end Why not just: class Invoice::Item < ActiveRecord::Base belongs_to:invoice end and move the file to: app/models/invoice/item.rb core domain at a glance John: Pros- Namespaces have an inherent hierarchy - Encourages more objects, clear path for them. Taming Stylesheets The recommendations are a lot like BEM - A front-end development methodology - learn more at: http://getbem.com/ John - Recommend a Readme.md for front-end specific code, or having front end specific guides in the readme. John - Have a process, and document your process. Have a system. John - Contractor (Frank Hock) - Recommended a very specific folder structure: Abstracts (Sizing, Boarders, Spacing)Base (Grid, Colors, images, Typography)Components (Buttons, Cards, Alerts)Page Specific CSS Picks: John: Elasticsearch with Bonsai - Such a great experience and amazing performance so far. JP: https://github.com/kelseyhightower/nocode

Growing Rails Applications in Practice: Part 1/3: New Rules For Rails Welcome to Iteration: A weekly podcast about programming, development, and design through the lens of amazing books, chapter-by-chapter An Inconvenient Secret: Large applications are large This book is about scaling your codebase. The amount of pain you feel should be logarithmic, not exponential. This is not about revolutionary design patterns or magic gems that make all your problems go away. Instead, we will show you how to use discipline, consistency, and organization to make your application grow more gently. Beautiful Controllers Should functionality go into the model or the controller?! "Less business logic in our controllers, the better" The authors argue for a standard controller design for every single user interaction. that is to say, it should only handle HTTP requests EVERYTHING is CRUD example of a stripped-down controller where Note controller never talks to the model directly. "Every controller action reads or changes a single model. even if an update involves multiple models, the job of finding and changing the involved records should be pushed to an orchestrating model" controllers should contain the minimum amount of glue to translate between the request, your model, and the response Relearning Active Record Data integrity with callbacks -> later in the book, we'll talk about how to not use so many callbacks bad: class Invite < ActiveRecord::Base def accept! (user) accepted = true Membership.create!(user: user) end end invite.update(accepted: true) # => circumventing the accept! method better: after_save :create_membership_on_accept private def create_membership_on_accept if accepted && accepted_changed? Membership.create!(user: user) end end User interactions without a database Not all user interactions need an active record model. Example: sign in form that uses sessions. when the form is submitted, you don't end up inserting a row in a table in your db start taking your controllers from hell -> putting that logic in your model (models from hell?) you know things are a pain when you have to use form_tag and can't use form_for one thing to note is that the example sends notifications (i.e. SMS, email) in their model and not their controller

Dive into the world of programming where hosts share invaluable insights from a beloved book. Discover the craft of coding as they reflect on their journeys and the evolution of tools like JavaScript. Hear about the challenges of language consistency in software projects and the importance of clean code. Learn how thorough testing can transform development, alongside tips for clarity in communication. Plus, explore productivity hacks with Better Touch Tool that promise to streamline your workflow!

Chapter 8 - Pragmatic Projects Season 2 - Episode 14 - Chapter 8 Part 2 John: Welcome to Iteration: A weekly podcast about programming, development, and design through the lens of amazing books, chapter-by-chapter. JP: This is part 2 of Chapter 8 - THE FINAL CHAPTER! 65 - Test state coverage, not code coverage Identify and test significant program states. Just testing lines of code isn't enough JP: Even if you test every single line of code - that's not what matters. What matters is how many different permutations of your app's state you have covered. drops mic John: Coverage tools are nice - but they only give you a window into the state passed into it. If you can extract state out into separate objects or methods to be able to test them decoupled from time. 66 - Find bugs once Once a human tester finds a bug, it should be the last time a human tester finds that bug. Automatic tests should check for it from then on. JP: We don't have time to find a bug more than once... "We have to spend our time writing new code - and new bugs" John: Step one of debugging - write a test that's failing. I broke this pattern this weekend. :( 67 - English is just a programming language Write docs as you would write code: honor the DRY principle, use metadata, MVC, auto-generation and so on JP: don't dread writing docs. it's part of your application. I think this tip is phrased in such a way to appeal to engineers. think of documentation writing as writing code, not writing literature John: I like this in theory - I'm having trouble getting tooling in place for this that makes sense. I really want to dynamically generate, external API docs, internal docs and user guides totally automatically. Super struggling to get anything moving in rails. 68 - Build documentation in, don't bolt it on Documentation created separately from code is less likely to be correct and up to date JP: sometimes you need documentation. obviously, name your variables well, but sometimes explain what a function does or why it does it. at OL we'll sometimes write include the GitHub issue number for a weird quirk or to explain why a test is testing for certain functionality. treat docs like code. part of the code, not separate from it John: I feel like this is a bit outdated. If written well modern languages really can be self-documenting. Basecamp really doesn't "do" code comments or internal docs - Per DHH - If there is a comment explaining a method or model I break it up further until it doesn't need explaining. I worship in the church of Henninger-Hansen. 69 - Gently exceed your users' expectations Come to understand your users' expectations, then deliver just that little bit more. JP: "Never lose sight of the business problems your application is intended to solve". John: One of my favorite parts of the job is delivering features users get super jazzed about. 7- - Sign your work Craftspeople of an earlier age were proud to sign their work. You should be, too "Anonymity, especially on large projects, can provide a breeding ground for sloppiness, mistakes, sloth, and bad code. [...] We want to see a pride of ownership. Your signature should come to be recognized as an indicator of quality. A really professional job. Written by a real programmer. A Pragmatic Programmer" JP: lol, git blame John: Take pride in what you do. Picks JP: https://github.com/sindresorhus/refined-github John: LG 22MD4KA-B UltraFine 4K Display 21.5" UHD 4096x2304 4xUSB-C Next week: Pragmatic Programmer in Practice - Book recap in the context of our real-life development work.

Chapter 8 - Pragmatic Projects Season 2 - Episode 13 - Chapter 8 Part 1 John: Welcome to Iteration: A weekly podcast about programming, development, and design through the lens of amazing books, chapter-by-chapter. JP: This is part 1 of Chapter 8 John: This chapter is all about "Pragmatic Projects" - Teams, Automation, Testing, Documentation Code quality and more. 60 - Organize teams around functionality Don't separate designers from coders, testers from data modelers. Build teams the way you would build code. JP: It's a mistake to think that the activities of a project - analysis, design, coding, and testing - can happen in isolation. i.e. Offers V2 at OL. Leaders of a team: needs at least 1 technical and 1 administrative personnel. Always think of the business goals John: It's nice to have lots of full stack devs - They can focus more on a "Module" than a specific tech or "side" of the project. 61 - Don't use manual procedures At the dawn of the age of automobiles, the instructions for starting a Model-T Ford were more than two pages long. With modern cars, you just turn the key—the starting procedure is automatic and foolproof. John: We are developers! Why would we do ANY tedious work? Example: Github's API pulls in PR's and notes. A shell script or batch file will execute the same instructions, in the same order, time after time JP: "We may have to build the starter and fuel injector from scratch, but once it's done, we can just turn the key from then on" i.e. deploys Let the computer do the repetitious, the mundane—it will do a better job of it than we would. 62 - Test early. Test often. Test automatically Tests that run with every build are much more effective than test plans that sit on the shelf. JP: In the Smalltalk world, they say, "Code a little, test a little" -> Get those small wins and make incremental changes John: Write tests to help guide design. 63 - Coding ain't done till all the tests run 'Nuff said JP: Keeping your feature branch green! John: ALL the tests - unit, integration, performance, staging, usability, QA 64 - Use saboteurs to test your testing Introduce bugs on purpose in a separate copy of the source to verify that testing will catch them. JP: After you have written a test to find a particular bug, cause the bug on purpose to make sure the test complains John: Code coverage analysis tools are very helpful Picks JP: Husky on NPM John: Hound - It's a service

Chapter 7 (pt. 2) - Steve Jobs teaches us how to wash clothes Season 2 Episode 12 John: Welcome to Iteration: A weekly podcast about programming, development, and design through the lens of amazing books, chapter-by-chapter. JP: Welcome to PART 2 of Chapter 7: "Before The Project" 56 - Start When You're Ready You've been building experience all your life. Don't ignore nagging doubts. JP: Follow your instincts when starting a project - but don't procrastinate - you can do this by prototyping. Proof of concepts are nice when you tackle the "hard" thing first. Prototype to discover John: Prototype, prototype! "as the prototype progresses you may have one of those moments of revelation when you suddenly realize that some basic premise was wrong." 57 - Some Things Are Better Done than Described Don't fall into the specification spiral - at some point you need to start coding. JP: "Program specification is the process of taking a requirement and reducing it down to the point where a programmer's skill can take over." - John: "natural language is really not up to the job." John: Even if it's just a screen recording and an ugly sketch prototype - manually scrolling around - WAAAY better than a written requriment doc. I rarely define work through written requirments. more than 1 bullet point alert specs will never capture every detail and nuance of the system and it's important to recognize this "A design that leaves the coder no room for interpretation robs the programming effort of any skill and art" - you may unearth some insights by beginning to code "Distrust environments where requirements are gathered, specifications are written, and then coding starts, all in isolation." there should be no artificial boundaries a healthy dev process encourages feedback from implementation and testing into the spec process there is a point of diminishing returns when specs get too details this reminds me of the early days of Whiz when I was a designer. everything was terribly isolated 58 - Don't Be a Slave to Formal Methods Don't blindly adopt any technique without putting it into the context of your development practices and capabilities This shows how dated the book is. examples of formal methods: CASE tools, waterfall development, "the spiral model", to today's UML diagrams. If this were written today, we'd talk about lean methodology, agile development, SCRUM don't get caught up in methodology. this is bad because it encourages isolation. "us vs. them" mentality between designers and programmers. the process should be more collaborative that's not to say you SHOULDN'T use formal methods. just remember that they're another tool You should work constantly to refine and improve your process 59 - Costly Tools Don't Produce Better Designs Beware of vendor hype, industry dogma, and the aura of the price tag. Judge tools on their merits. There are a lot of expensive project management tools. Are they worth it? John: Try not to think about how much a tool cost when you look at its output. Picks JP: If you're an Apple fan boy/girl, you might be interested in what Steve Jobs had to say about Object-Oriented Programming. This is an excerpt from a 1994 Rolling Stone interview where Steve (not a programmer) explains OOP in simple terms. Jeff Goodell: Would you explain, in simple terms, exactly what object-oriented software is? Steve Jobs: Objects are like people. They’re living, breathing things that have knowledge inside them about how to do things and have memory inside them so they can remember things. And rather than interacting with them at a very low level, you interact with them at a very high level of abstraction, like we’re doing right here. Here’s an example: If I’m your laundry object, you can give me your dirty clothes and send me a message that says, “Can you get my clothes laundered, please.” I happen to know where the best laundry place in San Francisco is. And I speak English, and I have dollars in my pockets. So I go out and hail a taxicab and tell the driver to take me to this place in San Francisco. I go get your clothes laundered, I jump back in the cab, I get back here. I give you your clean clothes and say, “Here are your clean clothes.” You have no idea how I did that. You have no knowledge of the laundry place. Maybe you speak French, and you can’t even hail a taxi. You can’t pay for one, you don’t have dollars in your pocket. Yet, I knew how to do all of that. And you didn’t have to know any of it. All that complexity was hidden inside of me, and we were able to interact at a very high level of abstraction. That’s what objects are. They encapsulate complexity, and the interfaces to that complexity are high level. John: Time Timer - https://www.timetimer.com/ - Pomodoro - Physical Device

Chapter 7 - Before The Project Season 2 Episode 10 John: Welcome to Iteration: A weekly podcast about programming, development, and design through the lens of amazing books, chapter-by-chapter. JP: Welcome to PART 1 of Chapter 7: "Before The Project." Starting a project can be a daunting task. There are a lot of unknowns and you might not know when you should start. We're going to talk about some of the things that will guide you when starting a project from scratch. Our focus will be gathering and understanding requirements For me, this is great because though I work at OL, I might be taking on a freelance client soon! 51 - Don't Gather Requirements - Dig For Them John: "Perfection is achieved, not when there is nothing left to add, but when there is nothing left to take away...." Requirements rarely lie on the surface. They're buried deep beneath the layers of assumptions, misconceptions, and politics JP: You can't just "gather" requirements as if they exist. You must do RESEARCH. Remember that you're solving business problems 52 - Work with a User to Think like a user It's the best way to gain insight into how the system will really be used JP: OBSERVE users for a week - this is much different than "thinking" like a user. I think that if you do the latter, you end up with preconceived notions based on your own assumptions. John: "It's important to discover the underlying reason why users do a particular thing, rather than just the way they currently do it." Learn understand business processes development Consider the politics (You write code + people get fired) 53 - Abstractions Live Longer than Details John: "...the simplest statement that accurately reflects the business need is best." John: Distilling real-world processes and people down into the most elegant and concise definition Invest in the abstraction, not the implementation. Abstractions can survive the barrage of changes from different implementations and new technologies Requirements are not architecture. Requirements are not design, nor are they the user interface. Requirements are need JP: Don't sweat implementation details. Requirements should be abstract 54 - Use a Project Glossary Create and maintain a single source of all the specific terms and vocabulary for a project JP: Create a literal glossary so that you and stakeholders can have a UBIQUITOUS LANGUAGE #domaindrivendesign - i.e. "client" and "customer" might be the same - they might be different. Also - you want this to live in a document that's shared. Don't know how serious that is but this is what the author's recommend for serious projects 55 - Don't think outside the box - find the box John: Gordius, the King of Phrygia, once tied a knot that no one could untie. It was said that he who solved the riddle of the Gordian Knot would rule all of Asia. So along comes Alexander the Great, who chops the knot to bits with his sword. Just a little different interpretation of the requirements, that's all... and he did end up ruling most of Asia. When faced with an impossible problem, identify the real constraints. Ask yourself: "Does it have to be done this way? Does it have to be done at all?" JP: Find the constraints of the box so that you can solve the problem at hand. You have to think of every possible avenue so that you don't dismiss potential solutions. I really like this: Consider the Trojan horse - a novel solution to an intractable problem. How do you get troops into a walled city without being discovered? You can be that "through the front door" was initially dismissed as suicide. Think of the most restrictive constraints first, and fit the remaining constraints within them. Too many quotes alert Many times a reinterpretation of the requirements can make a whole set of problems go away [...]. All you need are the real constraints, the misleading constraints, and the wisdom to know the difference. Picks JP: Swift - The Big Nerd Ranch Guide. Plenty of reasons why I want to learn Swift. John: Pusher - Websockets as a service.

Chapter 6 - Pragmatic Programer: John: Welcome to Iteration: A weekly podcast about programming, development, and design through the lens of amazing books, chapter-by-chapter. Small talk - We were off for the 4th - yada yada yada JP: This is part 2 of chapter 6, "While you are coding". Last week we talked about pragmatic practices while you are coding. Part 2 Tip 47 Refactor Early, Refactor Often Just as you might weed and rearrange a garden, rewrite, rework, and re-architect code when it needs it. Fix the root of the problem Construction vs. Gardening Gardening is less repeatable, less formulaic Time pressure is often used as an excuse for not refactoring. But his excuse just doesn't hold up: fail to refactor now, and there'll be far greater time investment to fix the problem down the road - when there are more dependencies to reckon with. Will there be more time available then? Not in our experience Advice: Keep track of the things that need to be refactored. If you cna't refactor something immediately, make sure that it gets placed on the schedule. Make sure that users of the affected code know that it is scheduled to be refactored and how it might affect them. Martin Fowler's tips for refactoring 1.) don't try to refactor and add functionality at the same time 2.) make sure you have good tests in place before you begin refactoring 3.) take short, deliberate steps What's your tolerance for pain? John: Real-World Complications You go to your boss or client and say, "This code works, but I need another week to refactor it." We can't print their reply. Tip 48 Design to Test Start thinking about testing before you write a line of code unit testing: testing a module in isolation to verify its behavior designing against a contract - code should fulfill its contract where do we place our tests? Rails proj. vs React Proj John: If your tests are hard to write - the design of your system is probably inelegant. It's a "design smell" if you are thinking - how the hell am I going to test this? Tip 49 Test Your Software, or Your Users Will Test ruthlessly. Don't make your users find bugs for you. writing tests isn't enough, you should be running your tests frequently. i.e. CirlceCi idea of "Test harnesses": should have a standard way of specifying setup and cleanup should have a method for selecting individual or all tests should have a means for analyzing output for expected results should have a standardized form of failure reporting today we have things like minitest and jest! it's amazing what tools we have in 2018. different test runners, continuous integration tools, things like Rollbar and bugsnag there's really no excuse not to be using these tools HOT QUOTE ALERT Testing is more cultural than technical: we can instill this testing culture in a project regardless of the language being used. John: Related: Re-create bugs in tests when debugging. every. time. Tip 50 Don't Use Wizard Code You Don't Understand Wizards can generate reams of code. Make sure you understand all of it before you incorporate it into your project Rails and its scaffold are "wizards" We are not against wizards [...] But if you do use a wizard, and you don't understand all the code that it produces, you won't be in control of your own application. You won't be able to maintain it, and you'll be struggling when it comes time to debug Rails generators vs. Create-react-app don't let it get to the point where it's the wizard's code and not your own PICKS JP: https://www.howtographql.com/ John: Jesus Castello - Ruby Guides on YouTube

In this podcast, hosts discuss the complexities of coding, emphasizing the importance of not relying on coincidences. They delve into algorithmic complexities, runtime efficiency, and the challenges of supporting IE 11. A humorous soldier metaphor is used to highlight the dangers of assumptions in coding. Tips are shared on estimating algorithm orders and optimizing code execution for efficient data processing.