Podcasts about clean code

Jemima Abu, Senior Product Engineer at CAIS, joins the podcast to unpack her no-fluff approach to functional programming in JavaScript. From why predictable code matters to how higher-order functions like map and reduce can save your sanity, Jemima breaks down real-world lessons on purity, immutability, and when it's okay to not be a functional purist. Links https://v3.jemimaabu.com https://www.jemimaabu.com https://www.linkedin.com/in/jemimaabu https://x.com/jemimaabu https://github.com/jemimaabu We want to hear from you! How did you find us? Did you see us on Twitter? In a newsletter? Or maybe we were recommended by a friend? Let us know by sending an email to our producer, Emily, at emily.kochanekketner@logrocket.com (mailto:emily.kochanekketner@logrocket.com), or tweet at us at PodRocketPod (https://twitter.com/PodRocketpod). Follow us. Get free stickers. Follow us on Apple Podcasts, fill out this form (https://podrocket.logrocket.com/get-podrocket-stickers), and we'll send you free PodRocket stickers! What does LogRocket do? LogRocket provides AI-first session replay and analytics that surfaces the UX and technical issues impacting user experiences. Start understand where your users are struggling by trying it for free at [LogRocket.com]. Try LogRocket for free today.(https://logrocket.com/signup/?pdr) Special Guest: Jemima Abu.

Ep 254Jaanus Kase: I turned on Advanced Data Protection for my iCloud accountNinja Repair: How to Reset Battery Health to 100% and Remove Notification after IOS18.3 (BMS Swap method) Mac Mini M4 Pro 64GB RAM Upgrade to 4TBSkype Is Finally Shutting Down on May 5 — MacRumorsMicrosoft is shutting down Skype — The VergeApple Announces $500B US Investment Plan, Adding 20K JobsApple's New U.S. Chip Factory to Produce AI Servers With High-End M5 ChipsApple introduces the new MacBook Air with the M4 chip and a sky blue colorApple unveils new Mac Studio, the most powerful Mac everApple reveals M3 Ultra, taking Apple silicon to a new extremeApple introduces iPad Air with powerful M3 chip and new Magic KeyboardA discussion between John Ousterhout and Robert Martin about differences between John's book "A Philosophy of Software Design" and Bob's book "Clean Code".ZahvalniceSnimano 8.3.2025.Uvodna muzika by Vladimir Tošić, stari sajt je ovde.Logotip by Aleksandra Ilić.Artwork epizode by Saša Montiljo, njegov kutak na Devianartu

In this week's episode of the podcast, Adam, Ben and Tim discuss various books that have significantly influenced their careers and coding philosophies. The conversation ranges from classics like 'Clean Code' and 'The Phoenix Project' to unexpected titles such as 'Fight Club' and 'The Four Agreements'.The discussion underscores the value of continuous learning and how different types of books can offer unique perspectives and practical wisdom.Follow the show and be sure to join the discussion on Discord! Our website is workingcode.dev and we're @workingcode.dev on Bluesky. New episodes drop weekly on Wednesday.And, if you're feeling the love, support us on Patreon.With audio editing and engineering by ZCross Media.Full show notes and transcript here.

Send us a textBefore you read "Cracking the Coding Interview" or "Clean Code", I want to offer a few books that you should read at every stage of your developer career from not-yet-hired to engineering manager.Me, sponsored? No.I just like sharing what's worked for me in the hopes it can work for you.If you have some good recommendations I didn't mention please let me and the rest of us know in the comments!Shameless Plugs(NEW) The Inner Circle - a highly customized program to take you from 0 to hired

From Netflix to revolutionizing education! Join us for an inspiring episode of Startup Anthology featuring Jose Moreno, former Netflix engineer and founder of groundbreaking ed-tech startup, Neulight. Jose shares his incredible journey, the challenges of building a tech company, and the lessons learned along the way. Whether you're an entrepreneur, tech enthusiast, or educator, this episode is packed with actionable insights to inspire your own path. Don't miss it! 

Helping developers identify issues with the computer code they're writing, from bugs to security vulnerabilities, is Sonar's mission. CEO Tariq Shaukat shares with Bloomberg Intelligence how 7 million developers and over 400,000 organizations are leveraging the company's platform, which analyzes more than 30 programming languages to reduce the business risk from bad code. In this episode of the Tech Disruptors podcast, Shaukat sits down with Bloomberg Intelligence analyst Niraj Patel to dive into the details of Sonar's scale in handling trillions of lines of coding, its addressable market size, disruptions from generative AI, the power of so-called clean code and much more.

In today's episode of Tech Talk, we're joined by Marcus Low, General Manager and VP for APJ at Sonar, a global leader in clean code solutions. With software development playing an increasingly critical role in Malaysia's digital economy, Marcus shares insights on the concept of Clean Code, why it's essential in modern software, and how it contributes to reducing technical debt and minimising project risks.Marcus discusses the unique challenges Malaysian developers face in implementing Clean Code practices and the evolving role of software companies in Malaysia's economy, especially as the nation becomes a hub for data centres, cloud services, and other digital infrastructure. As AI-generated code becomes more prevalent, he addresses the governance measures needed to ensure quality and security in software, as well as the repercussions of poor code quality in a highly interconnected IT ecosystem.

Código Limpio en Python: La Clave para un Desarrollo de Software ExitosoResumen del EpisodioEn este episodio, exploramos la importancia de escribir código limpio, testeable y de alta calidad en Python. Basándonos en un ensayo de Noah Gift de 2010, discutimos cómo el enfoque en la calidad del código desde el principio puede llevar a proyectos de software más exitosos y mantenibles.Puntos ClaveLa complejidad es el enemigo: Controlar la complejidad es esencial en el desarrollo de software.Pensamiento proactivo: Los desarrolladores exitosos piensan en la testabilidad y mantenibilidad desde el inicio.Desarrollo guiado por pruebas: Escribir pruebas antes o durante el desarrollo da forma al código de manera positiva.Métricas de calidad:Cobertura de códigoComplejidad ciclomáticaHerramientas útiles:Nose para pruebas unitarias y cobertura de códigoPylint y Pygenie para análisis estáticoLa Importancia de la Complejidad CiclomáticaDesarrollada por Thomas J. McCabe en 1976Mide el número de caminos independientes en el códigoSe recomienda mantener la complejidad por debajo de 10Alta complejidad se correlaciona con mayor probabilidad de erroresConclusiónEl desarrollo de software de calidad requiere un enfoque consciente en la testabilidad y la simplicidad. Las herramientas de análisis y las pruebas automatizadas son aliados valiosos, pero el verdadero éxito viene de una mentalidad enfocada en la calidad desde el principio.Recursos AdicionalesHerramienta de integración continua: HudsonLibros recomendados:"Software Tools" de Brian Kernighan"The Pragmatic Programmer" de Andrew Hunt y David Thomas

To kick off Elixir Wizards Season 13, The Creator's Lab, we're joined by Zach Daniel, the creator of Igniter and the Ash framework. Zach joins hosts Owen Bickford and Charles Suggs to discuss the mechanics and aspirations of his latest brainchild, Igniter—a code generation and project patching framework designed to revolutionize the Elixir development experience. Igniter isn't just about generating code; it's about generating smarter code. By leveraging tools like Sourcerer and Rewrite, Igniter allows developers to modify source code and batch updates by directly interacting with Elixir's AST instead of regex patching. This approach streamlines new project setup and package installations and enhances overall workflow. They also discuss the strategic implications of Igniter for the broader Elixir community. Zach hopes Igniter will foster a more interconnected and efficient ecosystem that attracts new developers to Elixir and caters to the evolving needs of seasoned Elixir engineers. Topics discussed in this episode: Advanced package installation and code generation improve the developer experience Scripting and staging techniques streamline project updates Innovative methods for smoother installation processes in Elixir packages High-level tools apply direct patches to source code Progressive feature additions simplify the mix phx.new experience Chaining installers and composing tasks for more efficient project setup Continuous improvement in developer experiences to boost Elixir adoption Encourage listeners to collaborate by sharing code generation patterns Introduction of a new mix task aimed at removing the "unless" keyword in preparation for Elixir 1.18 You can learn more in the upcoming book "Building Web Applications with Ash Framework" by Zach and Rebecca Links mentioned: https://smartlogic.io/ https://alembic.com.au/blog/igniter-rethinking-code-generation-with-project-patching https://hexdocs.pm/igniter/readme.html https://github.com/ash-project/igniter https://www.zachdaniel.dev/p/serialization-is-the-secret https://www.zachdaniel.dev/p/welcome-to-my-substack https://ash-hq.org/ https://hexdocs.pm/sourceror/readme.html https://smartlogic.io/podcast/elixir-wizards/s10-e09-hugo-lucas-future-of-elixir-community/ https://github.com/hrzndhrn/rewrite https://github.com/zachdaniel https://github.com/liveshowy/webauthn_components https://hexdocs.pm/elixir/Regex.html https://github.com/msaraiva/vscode-surface https://github.com/swoosh/swoosh https://github.com/erlef/oidcc https://alembic.com.au/ https://www.zachdaniel.dev/ Special Guest: Zach Daniel.

Nicole Rauch sorgt in dieser Revision dafür, dass Vanessa und Peter endlich mal anfangen, brauchbaren Programmcode zu produzieren. UNSER SPONSOR makandra bietet umfassende Unterstützung für Entwi…

Na escovação de bits dessa semana, Willian Martins e Hugo Marques se reunem para falar exclusivamente mal do livro "Clean Code", vale a pena seguir alguma coisa do livro? O bom mesmo é ser "Go Horse"? Como isso se aplica nas big techs? Ouça esse episódio e entenda melhor o que seguir ou não dessa prática, na nossa opinião é claro.

Carter Morgan and Nathan Toups discuss "A Philosophy of Software Design" by John Ousterhout. Join them as they talk about pulling complexity downward, the importance of code clarity, and the book's subtle rebuttals to Uncle Bob's Clean Code!

Etienne is very excited to welcome Jennifer Cwagenberg, Head of Engineering at Protopia AI, to the podcast for an engaging discussion spanning technology, farming, and even the intersection of the two. Jennifer shares insights into her unique lifestyle as a technologist and baroness of Texas, where she navigates the balance between rural tranquility and technological challenges.Their conversation delves into Jennifer's engineering journey, from her telecom beginnings to her diverse roles at companies like Match.com and Toyota, ultimately leading to her current role at Protopia AI. Jennifer provides a fascinating glimpse into Protopia's innovative approach to data protection for AI models, showcasing how their technology enables businesses to retain ownership of their data while still leveraging AI capabilities.Beyond technology, Jennifer sheds light on the parallels between farming practices and engineering principles, highlighting the importance of efficiency, adaptability, and continuous improvement in both areas. Drawing parallels between optimizing soil health and streamlining code, Jennifer emphasizes the value of making the right practices easy for engineers, thus fostering a culture of excellence and innovation.The conversation also touches on team dynamics, tool preferences, and the importance of enforcing coding standards to ensure maintainability and scalability of projects. Jennifer's dedication to creating unified developer experiences truly highlights her commitment to streamlining processes and maximizing productivity within her team.Join Etienne and Jennifer as they explore the fascinating intersection of technology, agriculture, and engineering philosophy, offering valuable insights for both seasoned professionals and aspiring technologists alike.Time Stamps:[2:07] - Jennifer points out how living in the countryside brings peace but lacks local community and good internet.[3:35] - Jennifer shares that she transitioned from telecom to startups, experiencing acquisitions and now focuses on AI data protection.[6:32] - Jennifer highlights the power and satisfaction of technology's immediate impact on society and individuals.[9:10] - Jennifer thrives on challenges across various domains, including farming, showcasing adaptability and passion for problem-solving in engineering.[12:48] - For her farm, adhering to no-till practices is crucial due to regulatory requirements and land conditions.[13:47] - How does Jennifer put her engineering prowess to good use on her farm?[16:19] - Both technology and farming require balancing effort - investing time wisely for impactful, achievable solutions.[18:57] - As VP of Engineering, Jennifer manages teams, contributes individually, and fills business needs.[20:23] - Protopia AI aims to unify developer experiences, leveraging VSCode for powerful collaboration and shared settings.[22:33] - Reading the book Clean Code impacted Jennifer profoundly, emphasizing best practices for writing maintainable, readable code.[25:30] - Jennifer points out that, as an engineer, managing various tasks from coding to security is challenging, but setting standards helps.[28:05] - Jennifer explains that enforcing pre-commit practices improves feedback speed, though it's not universal; CI/CD rules ensure code quality.Resources and Links Mentioned:Robert C. Martin - Clean Code: A Handbook of Agile Software CraftmanshipWe have 200+ CTOs in peer groups: Quick Testimonials VideoContact Etienne: Website / YouTube / LinkedIn / X / Instagram / The CTO Podcast WebsiteContact Jennifer: LinkedIn / Protopia AI WebsiteSchedule a meeting with Etienne on CalendlySee Privacy Policy at https://art19.com/privacy and California Privacy Notice at https://art19.com/privacy#do-not-sell-my-info.

Stephanie revisits the concept of "spiking"—a phase of exploration to determine the feasibility of a technical implementation or to address unknowns in feature requests—sharing her recent experiences with a legacy Rails application. Joël brings a different perspective by discussing his involvement with a client project that heavily utilizes the dry-rb suite of gems, highlighting the learning curve associated with adapting to new patterns and libraries. Joël used to be much more idealistic and has moved to be more pragmatic. Stephanie has moved the other way. So together, Stephanie and Joël engage in a philosophical discussion on being an idealistic versus a pragmatic programmer. They explore the concept of programming as a blend of science and art, where technical decisions are not only about solving problems but also about expressing ideas and building shared understandings within a team. Spike tasks episode (https://bikeshed.thoughtbot.com/414) dry-rb (https://dry-rb.org/) Working with Maybe talk (https://www.youtube.com/watch?v=43eM4kNbb6c) Problem solving with maybe (https://thoughtbot.com/blog/problem-solving-with-maybe) Programming as Theory Building (https://pablo.rauzy.name/dev/naur1985programming.pdf) The Pragmatic Programmer (https://pragprog.com/titles/tpp20/the-pragmatic-programmer-20th-anniversary-edition/) Transcript:  JOËL: Hello and welcome to another episode of the Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Joël Quenneville. STEPHANIE: And I'm Stephanie Minn, and together, we're here to share a bit of what we've learned along the way. JOËL: So, Stephanie, what's new in your world? STEPHANIE: So, a few weeks ago, we did an episode on spiking in response to a listener question. And I wanted to kind of revisit that topic for a little bit because I've been doing a lot of spiking on my client project. And for those who are not familiar, the way that I understand or define spikes is kind of as an exploration phase to figure out if a technical implementation might work. Or if you have a feature request with some unknowns, you can spend some time-boxed spiking to figure out what those unknowns might be. And I'm working on your typical legacy Rails application [laughs]. And I think one thing that we talked about last time was this idea of, at what point does spiking end up being just working on the feature [laughs]? And I think that's especially true in an older codebase, where you kind of have to go down a few rabbit holes, maybe, just to even find out if something will trip you up down the line. And the way I approached that this time around was just, like, identifying the constraints and putting a little flag there for myself. Like, these were rabbit holes that I could go down, but, you know, towards the initial beginning phase of doing the spiking, I decided not to. I just kind of bookmarked it for later. And once I had identified the main constraints, that was when I was like, okay, like, what kind of solutions can I come up with for these constraints? And that actually then helped me kind of decide which ones we're pursuing a little bit more to get, like, the information I needed to ultimately make a decision about whether this was worth doing, right? It kind of kept me...I'm thinking about, you know, when you are bowling with those safety guards [laughs], it keeps your ball from just rolling into the gutter. I think it helped with not going too deep into places that I may or may not be super fruitful while also, I think, giving me enough information to have a more realistic understanding of, like, what this work would entail. JOËL: Would you say that this approach that you're taking is inspired or maybe informed by the conversation we had on the episode? STEPHANIE: I was especially interested in avoiding the kind of binary of like, no, we can't do this because the system just, you know, isn't able to support it, or it's just too...it would be too much work. That was something I was really, like you said, kind of inspired by after that conversation because I wanted to avoid that trap a little bit. And I think another really helpful framing was the idea of, like, okay, what would need to be done in order to get us to a place where this could be possible? And that's why I think identifying those constraints was important because they're not constraints forever. Like, we could do something about them if we really wanted to, so kind of avoiding the, like, it's not possible, right? And saying like, "It could be. Here's all the things that we need to do in order to make it possible." But I think that helped shift the conversation, especially with stakeholders and stuff, to be a little bit more realistic and collaborative. So, Joël, what's new in your world? JOËL: So, I'm also on a new client project, and a thing that's been really interesting in this codebase is that they've been using the dry-rb suite of gems pretty heavily. And I've seen a lot about the suite of gems. I've read about them. Interestingly, this is kind of the first time that I've been on a codebase that sort of uses them as a main pattern in the app. So, there's been a bit of a learning curve there, and it's been really interesting. STEPHANIE: This is exciting to me because I know you have a lot of functional programming background, also, so it's kind of surprising that you're only now, you know, using something that explicit from functional languages in Ruby. And I'm curious: what's the learning curve, if not the paradigm? Like, what are you kind of encountering? JOËL: I think there's a little bit of just the translation. How do these gems sort of approach this? So, they have to do a couple of, like, clever Ruby things to make some of these features work. Some of these also will have different method names, so a lot of just familiarizing myself with the libraries. Like, oh, well, this thing that I'm used to having called a particular thing has a slightly different name here or maybe not having all of the utilities. I was like, oh, how do we traverse with this particular library? Then you have to, like, look it up. So, it's a lot of like, how do I do this thing I know how to do in, let's say, Elm? How do I translate that into Ruby? But then, also, some of the interplay of how that works in code that also does some very kind of imperative side effecty things also written by a team that is getting used to the pattern. And so, you'll sort of see things where people are pulling things in, but maybe you don't fully understand the deeper underlying approach that's meant to be used. STEPHANIE: Have you noticed any use cases where the dry-rb patterns really shine in your application? JOËL: A thing that's nice is that I think it really forces you to think about your edge cases in a way that sometimes Ruby developers play very fast and loose with "Yeah, whatever, it will never be nil." Push to production immediately start getting NoMethodError in your bug tracker. I never do this, by the way, but you know. STEPHANIE: [laughs]. JOËL: Speaking from a friend's experience [laughs]. STEPHANIE: Asking for a friend, yeah [laughs]. JOËL: I think a thing that I've sort of had to figure out sort of every time I deal with these patterns in different languages is just the importance of good composition and good separation. Because you're adding these sort of wrapper context around things, if you're constantly wrapping and unwrapping, you're like, check things inside, and then do the next thing, and then unwrap again and branch and check and do the next thing, that code becomes really clunky in a way that you just sort of expect to do if you're just writing code in regular Ruby with a nil. But it doesn't really work with a dry-rb maybe or a result. So, the pattern that I have found that works really well is to extract sort of every operation that can be, let's say, that could fail so that it would give you a result back. Extract that out into its own separate function that will construct a success or a failure, and then have your sort of main code that wants to then do a bunch of these things together. All it does is use some of the dry-rb helper methods to compose all of these together, whether that's just some sort of, like, do notation, or binding, or fmap, or something like that, which allows you to have sort of individual chunks that can fail, and then one sort of aggregator piece of code that just finds a way to combine all of them nicely. And that avoids you having to do all this repetition. STEPHANIE: Yeah, that makes a lot of sense. JOËL: It's a pattern, I think; I had to learn the hard way when I was working with Elm. Because if you're taking a potential nullable value and then you want to do things with it but then that potential operation is also nullable because the input was potentially null, and then that just sort of propagates all the way down the chain. So, my whole chain of functions now is doing checks for nullability. And in Ruby, I could just be like, no, I checked it in the first function. I can then just trust that it's not null down the chain. Elm doesn't do the like, trust me, bro. The compiler will force you to validate every time, and then the code just blows up, and it gets really painful. So, I had to start thinking about new models of thinking that would separate out code that actually needs to care and code that doesn't need to care about nullability. And I wrote an article about that. That turned into actually a conference talk as well. And these sort of ideas have served me really well at Elm. And I think these translate pretty well to dry-rb as well. That's something that I'm exploring, but the principles seem like they're not tied to a particular language. STEPHANIE: Yeah, and it's kind of cool that you experienced all of that in working with Elm, where a compiler was there to yell at you [laughs] and kind of forcing you to...I don't know if do the right thing is the right word, but kind of think in the way that it wants you to think. And I can see people who are coming from Ruby and starting to experiment with dry-rb maybe needing a bit of that since it's not built-in in the tooling, just in a recoder view or just in conversations among devs. JOËL: [inaudible 09:26] Beyond just the idea of wrapping your values and making sure you check them all the time, there are patterns that make that easier or more painful. And even in something like Elm, the compiler would yell at me would make sure I could not have a runtime error by forgetting to check for nullability. It did not prevent me from writing monstrosities of nested repeated conditionals checking if nil, if nil, if nil. That I had to figure out some sort of, like, higher-level patterns that play nicely with that kind of software. And I think these are things that people have to sort of encounter, feel the pain, feel the frustration, and then move into those better patterns after the fact. And sometimes that's not easy because it's not obvious why that's a valuable pattern to approach. STEPHANIE: Yeah, I agree completely. Speaking of following patterns and kind of arriving at maybe an ideal version of [chuckles], you know, what you'd like your code to do, you know, to build what you are looking to build [laughs]...this is my very poor attempt at a smooth transition that Joël [laughter] manages to be able to do [laughs] whenever we're trying to shift into the topic of the episode. Anyway, today, we were hoping to talk a little bit about this idea between being an idealistic programmer and a pragmatic programmer and the different journeys that we've each been on in arriving kind of how to balance the two. JOËL: Yeah, you know, I think neither of these are absolutes, right? It's a spectrum. You probably move around that spectrum from day to day, and then probably, like, more general trends over your career. But I'm curious, for you today, if you had to pick one of those labels, like, which sort of zone of the spectrum would you put yourself in? Do you think you're more idealistic or more pragmatic? STEPHANIE: I think I'm in a more of an idealistic zone right now. JOËL: Would you say you're kind of like middle trending idealistic or kind of, like, pretty far down the idealistic side? STEPHANIE: Middle trending idealistic. I like that way of describing it. I want to know where you are. And then I kind of wanted to try to take a step back and even define what that means for both of us. JOËL: Right, right. I think the way I'd probably describe myself is a recovering idealist. STEPHANIE: Oof. Yeah [laughs]. JOËL: I think there was a time where I was really idealistic. I really like knowing sort of underlying theory of software construction, broader patterns. By patterns here, I don't mean necessarily, like, you know, the Gang of Four, but just general sort of approaches that work well and using that to guide my work. But I've also been trending a lot more into the, like, pragmatic side of things in the past few years. STEPHANIE: So, could you kind of tell me a little bit about what does pragmatic mean for you and what does ideal mean for you? JOËL: So, I think the pragmatic side of me it's about delivering working software. If you're not shipping anything, you know, the most beautiful piece of art that you've created just warms your heart is useless. So, I think I'm sort of at the extreme end of pragmatism, right? It's all about shipping and shipping fast. And, in the end, that's generally the goal of software. On the more idealistic side, the sort of doing everything kind of perfect or by the book, or, you know, maybe in a way that brings you personal satisfaction, oftentimes, at the expense of shipping and vice versa. Sometimes shipping comes at the expense of writing absolutely terrible code, but, of course, you know, there's value in both. Shipping is what actually delivers value to your users, your company, yourself if you're using the software. But if you're not following patterns and things, you're often stuck in a really short-term thinking loop, where you are maybe delivering value today at the cost of being able to deliver value tomorrow or writing code that is unreadable or code that is difficult to collaborate on. So, more than just me shipping an individual feature, I've got to think about, while I'm working with a team, how can I help them be able to ship features or build on top of my work for tomorrow? So, that's sort of how I visualize the field. I'm curious what the words idealism and pragmatism mean to you. STEPHANIE: Yeah. I agree with you that pragmatism is, you know, this idea of delivering working software. And I think I have seen it very, you know, kind of condensed as, like, moving quickly, getting stuff out the door, basically, like, end result being, like, a thing that you can use, right? I think I've personally been reassessing that idea a lot because I'm kind of almost wondering like, well, what are we moving quickly for [laughs]? I sometimes have seen pragmatism just end there being like, okay, like, it's all about velocity. And then, I'm kind of stuck being like, well, if you write working software for, you know, completely the wrong thing, is that still pragmatic? I don't know. So, that's kind of where I'm at these days with–I'm feeling a little bit more suspect of pragmatism, at least wanting to make sure that, especially with the people that I'm working with day to day, that we're agreeing on what that means and what success means. And then, as for idealism, I think also, actually, I now have a little bit of duality in terms of how I understand that as well. One of them being, yes, definitely, like, by the book or, like, by the ideas that we've, you know, some very smart people [laughs] have figured out as, like, this is clean or good quality, or these are the patterns to, you know, make your code as, again, as clean, I don't know, kind of putting air quotes around that, as possible. And then, I actually like what you really said about code that warms your heart [laughs] that you feel, like, really moved by or, like, just excited about or inspired by because I think that can also be a little bit different from just following theories that other people have defined. The more I spend doing this stuff, the more I am convinced that writing software is actually a very creative practice. And that's something that I've, like, definitely had to balance with the pragmatism a bit more because there are days when it's just not coming [chuckles], you know, like, I just stare at a blank, new file. And I'm like, I can't even imagine what these classes would be because, like, that creative part of my brain just, like, isn't on that day. So, that's kind of where I'm sitting in terms of, like, what idealistic programming kind of seems to me. JOËL: There's definitely an element of programming that feels like self-expression, you know, there are parameters around that. And working with a team, you probably all sort of, like, move towards some average. But I would definitely say that there is some element of self-expression in coding. STEPHANIE: Yeah, 100%. Have you heard about this paper called Programming as Theory Building? JOËL: The name sounds vaguely familiar, but I can't place the main idea in my mind right now. STEPHANIE: It's, like, an academic-ish paper from the 80s. And I'll link to it in the show notes because I can't remember the author right now. But the idea is writing code is actually just one way of expressing a theory that we are building. In fact, that expression doesn't even....it's like, it's impossible for it to fully encapsulate everything that was involved in the building of the theory because every decision you make, you know, you decide what not to do as well, right? Like, all the things that you didn't encode in your application is still part of this theory, like stuff that you rejected in order to interpret and make abstract the things that you are translating from the quote, unquote "real world" into code. That really stuck with me because, in that sense, I love this idea that you can create your own little world, right? Like, you're developing it when you code. And that is something that gets lost a little bit when we're just focused on the pragmatic side of things. JOËL: Where things get tricky as well is that when you're working with a team, you're not just building your own little world. You're building a shared world with shared mental models, shared metaphors. That's where oftentimes it becomes important to make sure that the things that you are thinking about are expressed in a way that other people could read your code and then immediately pick up on what's happening. And that can be through things like documentation, code comments. It can also be through more rigorous data modeling. So, for example, I am a huge fan of value objects in general. I tend to not have raw numbers floating around in an app. I like to wrap them in some kind of class and say, "Hey, these numbers that are floating around they actually represent a thing," and I'll name that thing so that other people can get a sense that, oh, it is one of the moving parts of this app, and then here are the behaviors that we expect on it. And that is partly for sort of code correctness and things like that but also as a sort of way of communicating and a way of contributing to that shared reality that we're creating with the team in a way that if I just left a raw number, that would be almost, like, leaving something slightly undefined. Like, the number is there. It does a thing, but what it does is maybe a little bit more implied. I know in my mind that this is a dollar amount, and maybe there's even a comment above it that says, "Dollar amount." But it makes it a little bit harder for it to play in with everybody else's realities or view of the system than if it were its own object. STEPHANIE: Yeah, I like what you said about you're building a shared world with your fellow colleagues. And that helped explain to me why, as some people say, naming is the hardest part about building software because, yeah, like you said, even just saying you are wanting to make a method or class expressive. And we talked about how code is a way of expressing yourself. You could, like, name all your stuff in Wingdings [laughs], but we don't. I actually don't know if you could do that. But that was, for some reason, what I imagined. I was like, it's possible, and you could deliver software in complete gibberish [laughs]. JOËL: In theory, could you say that naming your variables as emoji is the most expressive way? Because now it's all emotions. STEPHANIE: A picture is worth a thousand words, as they say. JOËL: So, this variable is the frowny face, upside-down smile face. It doesn't get more expressive than that. STEPHANIE: At a former company, in our Slack workspace, I had a co-worker who loved to use the circus tent emoji to react to things. And, like, I'm convinced that no one really knew what it meant, but we also kind of knew what it meant. We were just like, oh yeah, that's the emoji that she uses to express amusement or, like, something a little bit ironic. And we all kind of figured it out [laughs] eventually. So, again, I do think it's possible. I bet someone has done, like, a creative experiment with writing an application in just emojis. This is now going to be some research I do after this episode [laughter]. JOËL: It is fun when you have, like, a teammate. You know they have the signature emoji that they respond to on things. STEPHANIE: Yep. Absolutely. So, you know, we kind of spent a little bit of time talking about idealism. I actually wanted to pull back to the idea of pragmatism because, in preparation for this episode, I also revisited my copy of The Pragmatic Programmer. Are you familiar with this book? Have you read it at all? JOËL: I have read it. It's been probably ten years. We did, I think, a book club at thoughtbot to go through the book. STEPHANIE: I was skimming the table of contents because I was curious about, again, that, like, definition of pragmatism. You and I had kind of talked about how it can be short-sighted. But what I was actually pretty impressed with, and I imagine this is why the book holds up, you know, after decades, is success for them also means being able to continue to deliver quality software. And that idea of continuity kind of implied, to me, that there was an aspect of, like, making sure the quality meets a certain threshold and, like, incorporating these theories and doing the best practices because they're thinking about success over time, right? Not just the success of this particular piece that you're delivering. JOËL: I would say most people in our industry are sort of balancing those two objectives, right? They're like, we want to have a decent velocity and ship things, but at the same time, we want to be able to keep delivering. We want a certain threshold of quality. In between those two objectives, there is a sea of trade-offs, and how you manage them are probably a little bit part of your personality as a developer and is probably also, to a certain extent, a function of your experience, learning sort of when to lean more into taking some shortcuts to ship faster and when to double down on certain practices that increase code quality, and what aspects of quality value more than others because not all forms of quote, unquote, "quality" are the same. I think a sort of source of danger, especially for newer developers, is you sort of start on almost, like, a hyper-pragmatic side of things because most people get into software because they want to build things. And the ultimate way to build is to ship, and then you sort of encounter problems where you realize, oh, this code is really clunky. It's harder and harder to ship. Let me learn some elements of code quality. Let's get better at my craft so that I can build software that has fewer bugs or that I can ship more consistently. And that's great. And then, you sort of run into some, like, broader sort of theories of programming: patterns, structures, things like that. And it becomes very easy to sort of blindly copy-paste that everywhere to the point where I think it's almost a bit of a meme, the, like, intermediate programmer who's read Clean Code or the Design Patterns book and is just now, like, applying these things blindly to every piece of code they encounter to the annoyance of the entire team. STEPHANIE: I think you just about described my trajectory [laughter], though hopefully, I was not so obnoxious about [laughs] it for my team having to deal with my, like, discovering [laughs] theories that have long been used. JOËL: I think we kind of all go through that journey to a certain extent, right? It's a little bit different for every one of us, but I think this is a journey that is really common for developers. STEPHANIE: Yeah. One thing I frequently think about a lot is how much I wished I had known some of that theory earlier. But I don't think I have an answer one way or another. It's like; I'm not sure if having that knowledge earlier really would have helped me because I've also definitely been in...I'm just thinking about, like, when I was in college in lectures trying to absorb theories that made no sense to me because I had no, like, practical experience to connect it to. It's almost, like, maybe there is, like, that perfect time [laughs] where it is the most valuable for what you're doing. And I don't know. I kind of believe that there is a way to bridge that gap. JOËL: I mean, now we're kind of getting into an element of pedagogy. Do you sort of teach the theory first, and then show how to apply it to problems? Or do you show problems and then introduce bits of theory to help people get unstuck and maybe then cap it off by like, oh, these, like, five different, like, techniques I showed you to, like, solve five different problems, turns out they all fit in some grand unified theory? And, like, here's how the five things you thought were five different techniques are actually the same technique viewed from five different perspectives. Let me blow your mind. STEPHANIE: That's a Joël approach [laughter] to teaching if I've ever heard one. JOËL: I'm a huge fan of that approach. Going back to some of the, like, the functional programming ideas, I think that's one that really connected for me. I struggled to learn things like monads, and functors, and things like that. And I think, in my mind, these two approaches is like the Haskell school of teaching and the Elm school of teaching. Haskell will sort of say, "Hey, let me teach you about this theory of monads and all these things, and then, we'll look at some ways where that can be applied practically." Whereas Elm will say, "No, you don't need to know about this. Let's look at some practical problems. Oh, you've got null values you need to check. Here's how you can, like, handle nullability in a safe way. Oh, you've got a bunch of HTTP requests that might resolve in random order, and you want to, like, deal with them when they all come back. Here's some tips on how you can do that." And then, you have three or four things, and then, eventually, it just sort of lets you say, "Wait a minute, all of these problems are sort of all the same, and it turns out they all fit in some unified theory." And then, the light bulb goes off, and you're like, "Ooh, so now when I'm dealing with unknown blobs of Jason trying to parse data out of them, I'll bet I can use the same techniques I used for chaining HTTP requests to dig multiple dependent pieces of JSON." STEPHANIE: Yeah. And that's so satisfying, right? It really is kind of leveling up in that Galaxy Brain meme sort of way. JOËL: Yeah. And that's maybe to a certain extent even a value of idealism because if you build your system in such a way that it follows some of these patterns, then insights and intuitions that people have in one part of your code can then carry to other parts of your code, and that's incredibly powerful. STEPHANIE: Yeah. And I almost wonder because you also mentioned kind of where you end up on the spectrum is a function of your experience. I wonder if us, you know, being consultants and seeing patterns across many applications also kind of contributes to the striving for idealism [laughs]. JOËL: It's kind of both, right? Because there's very high incentive to ship pretty rapidly, especially if you're on a shorter engagement or if you're on a project that has a shorter timescale. But also, yes, because you've seen so many projects, you've seen how things can go wrong. Also, you've seen the same problem from 20 different perspectives that are all slightly different. And so, some of those broader patterns can start emerging in your head. STEPHANIE: Yeah, honestly, I think that's kind of the work that I enjoy the most in consulting because a lot of clients bring us on when they're like, "Hey, like, we've reached a point where our velocity has slowed down. Like, can you help us unstick our developers?" And that's actually when I've found that leaning on the theories and maybe a little bit of idealism is actually really useful because I'm kind of providing those tools to developers at this time when they need it. That's kind of why I have been saying trending idealism because I have found that particularly useful at work. JOËL: There's an element here of, like, looking at a bunch of different use cases and then finding some sort of unifying model or theory. And that's a word that I think programmers have a love-hate relationship with: Abstraction. I don't know about you, but designing abstractions is a lot of fun for me. I love designing abstractions. I have always loved designing abstractions. It's not always the best use of my time, and it's not always the best thing for a codebase. STEPHANIE: Ooh, okay, okay. This was a good transition. I hear you that, like, yeah, love-hate relationship. It's hard. That's kind of where I've ended up. It's really hard. And I think it's because it requires that creative thinking. JOËL: It requires that creative thinking. And then also, like, it requires you to sort of see more broadly, a more broad picture. What are the things that are connected, the things that are disconnected, even though they seem related? And, like, being able to sort of slice those similarities from each other. STEPHANIE: Yeah. I agree. And the interesting part is that, like, a lot of the time you just don't know yet. And you kind of have to come back to reality and admit that you don't know yet, you know, got to come back to earth, take a look around, and, yeah, you can go through the thought exercise of thinking [laughs] about all of the possibilities, and I imagine you could do that forever [laughs]. JOËL: I mean, that's why we have heuristics like the rule of three that says, "Don't abstract something out or attempt to DRY code until you've seen three use cases of it." So, maybe leave a little bit of duplication or a little bit of maybe not perfectly factored code until you have a couple of more examples. And the sort of real picture starts emerging a little bit more. STEPHANIE: So, I think we are kind of at this topic already, but was there a moment or was there something that kind of helped you realize, like, oh, I can't be in that space of imagining abstractions [laughs] forever when I have to deliver software? Like, what changed for you to be the, as you said yourself, recovering idealist and having to maybe employ some more pragmatic heuristics? JOËL: And I think, for me, it's partly being a consultant and being in a lot of projects and having that pressure to work with deadlines and sort of not having an infinite canvas to paint with, having to sort of fit some of my grand ideas into the reality of, we've got a week or two weeks to get this thing done, and also working with a team, and some ideas don't work well with every team. Every team is kind of at a different place. And abstractions sort of only serve you as well as they are useful to not only you but the team at large. So, if a team is not comfortable with a set of abstractions, or it's sort of, like, too far down a path, then that can be really challenging. And that's where something like the dry-rb set of gems, which has some really fun abstractions like a mental model for doing things, depending on the team, that can be a really heavy lift. And so, as much as I like those patterns, I might think long and hard before I try to push this on a whole team. STEPHANIE: Yeah, I kind of had to navigate a situation like that recently, where I was doing a code review, and I had left some suggestions about refactoring to encapsulate some responsibilities better. And then, I was like, oh, and then I noticed another thing that we could do to make that easier. And it, you know, definitely can start to spiral. And the author, you know, kind of responded to me and said, "Hey, like, I really appreciate these comments, but we are a bit tight on deadline for this project. So, is it okay if I, like, revisit this when we've delivered it?" And, you know, I was just like, "Yeah, it's totally up to you." At the end of the day, I want whoever's authoring this code to have, like, full agency about how they want to move forward. And it was really helpful for me to get that context of, like, oh, they're a bit tight on the deadline because then I can start to meet them where they're at. And maybe I can give some suggestions for moving towards that ideal state, but ones that are lower left, and that is still better than nothing. JOËL: That sounds awfully pragmatic. STEPHANIE: [laughs] JOËL: Moving in a positive direction, we're getting halfway. It's better than nothing. That's very pragmatic. STEPHANIE: Hmm. Wow. But it's pragmatically moving towards idealism. JOËL: [laughs] STEPHANIE: If that is even possible [laughs]. JOËL: Uh-huh. STEPHANIE: That's maybe the book that I'm going to write, not The Pragmatic Programmer, but The Pragmatically Idealistic Programmer [laughs]. JOËL: The Pragmatic Idealist. STEPHANIE: Ooh, yeah, I like that. Okay. Watch out for that book coming 2030 [laughter], written by me and Joël. JOËL: So, I think you brought up a really interesting point, which is the idea of pragmatism versus idealism when it comes to code review. Do you find that you think about these ideas differently when reviewing somebody else's code versus when you write your own? STEPHANIE: Oooh, yeah. I'm not sure exactly why, but definitely, when I'm reviewing someone else's code, I'm already in the headspace of, you know, I have some separation, right? Like, I'm not in the mode of thinking very hard [laughs] about what I'm creating. I'm just, like, in the editing kind of phase. And then, I can actually pull more from different theories and ideas, and I find that actually quite easier. When I'm writing my own code, it's just whatever comes out, right? And then, hopefully, I have the time to revisit it and give it a scan, and then start to integrate the, like, idealistic theories and the patterns that I would like to be using. But it definitely...for patterns that I feel a lot more confident about or more familiar with, they just come out mostly kind of oriented in that way if I have the time, or sometimes I will make the time, you know. I'll just say, "It's not done yet," because I know it can be better. I think that could be another, like, pragmatically idealist way of handling that. JOËL: [laughs] STEPHANIE: Right? It's just telling people, "I'm not done." [laughs] It's not done until I do at least give it an attempt. JOËL: So, it's kind of a two-phase thing when you're writing your own code, whereas it's only a single phase when you're reviewing somebody else's. STEPHANIE: Yeah. Yeah. But, like I said earlier, it's like, I also really believe that I don't want to impose any of my ideas [laughs] onto others. I really believe that people have to arrive at it on their own. So, it used to bother me a little bit more when I was just like, oh, but this way is better [laughs]. When people wouldn't get on board, I would be sad about it. But as long as I know that I, like, left that comment, then I can give myself a pat on the back for trying to move towards that ideal state. What about you [laughs]? JOËL: I think this is probably also where I'm, like, now a recovering idealist. There was a time where I would leave a ton of comments on someone's PR. I almost had a view of like, how can I help you get your PR to be the best it can possibly be? And sometimes, if you start with something that's very rough around the edges, you're leaving a lot of comments. And I've been that guy who's left 50 comments on a PR. In retrospect, I think that was not being a good teammate. STEPHANIE: Hmm. JOËL: So, I think maybe my mental model or my, like, goal for PR review has changed a little bit. It's less about how can I help you make your code the best it can possibly be? And a how can I help you get your code to mergeable? And it's possible that mergeable means best that it can possibly be, but that's usually not the case. So, I'm going to give you some feedback: some things that confuse me, maybe raise one or two patterns that are existing in the app that maybe you weren't aware of that you should maybe consider applying. Maybe I'll raise a couple of ideas that are new, but that apply here. And those might just be a, "Hey, let's just think about this. Maybe we don't want to do this in this PR, but maybe we want to look at them at some point. Or we should be thinking about this in a sort of rule of three situation. If we see this come up another time, maybe consider introducing a strategy pattern here, or maybe consider making this a value object, or separating these side effects from these pure behavior." But it's more of a dialogue about how can I help you get your PR to the point where it is mergeable? STEPHANIE: Yeah. Another thing I thought about just now is both are meaningful or, like, both can provide meaning in different ways, and people ascribe different amounts of meaning to both; where I had worked with someone, a client developer before, who was not super interested in doing any kind of refactoring or, like, any, you know, second passes for quality. Because, for him, like, he just wanted to ship, right? That was where he found meaning in his work. Whereas that actually made my work feel a lot more meaningless [chuckles] because I'm like, well, if we're just kind of hands on a keyboard, like robots shipping code, I don't know, that doesn't feel particularly motivating for me. You know, I do want to employ some of that craft a little bit more. JOËL: And, I guess, yeah, idealism versus pragmatism is also...it's a personal individual thing. There's an element where it's a team decision, or at least a sense of, like, how much quality do we need at this point in the life cycle of the project? And what are the areas where we particularly want to emphasize quality? What are our quality standards? And that's, to a certain extent, consensus among the team that it's individual members. And it's also coming from team leadership. STEPHANIE: Yeah. Yeah, exactly. I mentioned that, you know, just to, I think, shed a little bit of light that it's usually not personal, right [laughs]? There's that part of understanding that is really important to, yeah, like, keep building this shared world of writing software, and, hopefully, it should be meaningful for all of us. JOËL: I think a few takeaways that I have would be, one, the value of, like, theory and idealism. These things help you to become a better developer. They help you to spot patterns. It's probably good to sort of have in the background always be learning some new thing, whether that's learning a new set of patterns, or learning some mental models, thinking about, oh, the difference between side effects and pure code, learning about particular ways of structuring code. These are all things that are good to have in your back pocket to be able to apply to the code that you're doing, even if it's a sort of after-the-fact, hey, I've done a similar task three different times. Is there a broader principle? But then, also, take the time to really make sure that you're focusing on shipping code, and maybe that's learning to work in smaller chunks, working iteratively, learning to scope your work well. Because, in the end, delivering value is a thing that is something that we could all probably benefit from doing more of. And then, finally, taking some time to self-reflect, a little bit of self-awareness in this area. What are the aspects of pragmatism and idealism that you find personally meaningful? What are the elements that you think bring value to your work, to your team? And let that sort of guide you on your next code writing or PR review. STEPHANIE: On that note, shall we wrap up? JOËL: Let's wrap up. STEPHANIE: Show notes for this episode can be found at bikeshed.fm. JOËL: This show has been produced and edited by Mandy Moore. STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show. JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter. STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email. JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week. ALL: Byeeeeeeee!!!!!! AD: Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us. More info on our website at: tbot.io/referral. Or you can email us at: referrals@thoughtbot.com with any questions.

In Elixir Wizards Office Hours Episode 2, "Discovery Discoveries," SmartLogic's Project Manager Alicia Brindisi and VP of Delivery Bri LaVorgna join Elixir Wizards Sundi Myint and Owen Bickford on an exploratory journey through the discovery phase of the software development lifecycle. This episode highlights how collaboration and communication transform the client-project team dynamic into a customized expedition. The goal of discovery is to reveal clear business goals, understand the end user, pinpoint key project objectives, and meticulously document the path forward in a Product Requirements Document (PRD). The discussion emphasizes the importance of fostering transparency, trust, and open communication. Through a mutual exchange of ideas, we are able to create the most tailored, efficient solutions that meet the client's current goals and their vision for the future. Key topics discussed in this episode: Mastering the art of tailored, collaborative discovery Navigating business landscapes and user experiences with empathy Sculpting project objectives and architectural blueprints Continuously capturing discoveries and refining documentation Striking the perfect balance between flexibility and structured processes Steering clear of scope creep while managing expectations Tapping into collective wisdom for ongoing discovery Building and sustaining a foundation of trust and transparency Links mentioned in this episode: https://smartlogic.io/ Follow SmartLogic on social media: https://twitter.com/smartlogic Contact Bri: bri@smartlogic.io What is a PRD? https://en.wikipedia.org/wiki/Productrequirementsdocument Special Guests: Alicia Brindisi and Bri LaVorgna.

Welcome back to another insightful discussion on software development! In this podcast episode, Michael and Rob delve into the critical topic of CYA practices—Cover Your Ass practices—in the realm of software development. As seasoned professionals in the industry, we've encountered our fair share of challenges and learned valuable lessons along the way. Our goal today is to share some of these experiences, insights, and strategies with you, our audience so that you can navigate your own projects more effectively and avoid common pitfalls. Understanding the Importance of CYA Practices We start our conversation by reflecting on recent experiences with clients who inadvertently overlooked crucial details in their project agendas. From forgotten tasks to budget uncertainties and unexpected data issues, these situations underscore the importance of robust CYA practices. Whether it's about status reporting, communication, or documentation, having a clear paper trail ensures accountability and transparency. The Role of Clean Code and Documentation One of the cornerstones of CYA practices is maintaining clean code and thorough documentation. Michael and Rob emphasize the significance of writing code that is functional, well-documented, and easy to understand. Clean code serves as a source of truth, enabling developers to navigate through the project's intricacies efficiently. Additionally, comprehensive documentation acts as a blueprint for the software's functionality, facilitating smoother transitions for future developers or team members. Integrating Testing into CYA Practices A crucial aspect of CYA practices is integrating robust testing methodologies into the development process. We discuss the importance of test-driven development, where tests serve as documentation and use cases for the software's behavior. By prioritizing testing at every stage, developers can catch bugs early, ensure code reliability, and mitigate risks associated with unforeseen edge cases. Navigating Challenges and Motivating Team Members As developers, we often encounter situations where stakeholders might find adherence to CYA practices tedious or overlooked. However, we stress the importance of staying motivated and focused on the long-term benefits of these practices. Whether it's adhering to requirements, addressing edge cases, or maintaining testing standards, prioritizing quality over shortcuts ultimately pays off in the form of stable, reliable software. Embracing a Culture of Accountability In a rapidly evolving software landscape, embracing a culture of accountability is paramount. Everyone from project managers to developers plays a role in upholding CYA practices and ensuring project success. By fostering open communication, thorough documentation, and a commitment to quality, teams can mitigate risks, streamline development processes, and deliver exceptional results. As we conclude our discussion, Michael and Rob reiterate the importance of CYA practices in software development. By embracing documentation, clean code, testing, and a culture of accountability, developers can navigate complex projects more effectively and mitigate risks along the way. Remember, the extra effort invested in CYA practices today can save countless headaches tomorrow, ensuring success in the ever-changing software development landscape. Thank you for tuning in to another episode of our podcast. We hope you found this discussion insightful and valuable for your own software development endeavors. Additional Resources CYA Documentation: Getting Started With Consulting Cover Your Assets – The CYA Anti-Pattern The Importance Of Writing Readable Code Clean Code Handbook Software Craftsmanship Behind the Scenes Podcast Video

The Elixir Wizards Podcast is back with Season 12 Office Hours, where we talk with the internal SmartLogic team about the stages of the software development lifecycle. For the season premiere, "Testing 1, 2, 3," Joel Meador and Charles Suggs join us to discuss the nuances of software testing. In this episode, we discuss everything from testing philosophies to test driven development (TDD), integration, and end-user testing. Our guests share real-world experiences that highlight the benefits of thorough testing, challenges like test maintenance, and problem-solving for complex production environments. Key topics discussed in this episode: How to find a balance that's cost-effective and practical while testing Balancing test coverage and development speed The importance of clear test plans and goals So many tests: Unit testing, integration testing, acceptance testing, penetration testing, automated vs. manual testing Agile vs. Waterfall methodologies Writing readable and maintainable tests Testing edge cases and unexpected scenarios Testing as a form of documentation and communication Advice for developers looking to improve testing practices Continuous integration and deployment Links mentioned: https://smartlogic.io/ Watch this episode on YouTube! youtu.be/unx5AIvSdc Bob Martin “Clean Code” videos - “Uncle Bob”: http://cleancoder.com/ JUnit 5 Testing for Java and the JVM https://junit.org/junit5/ ExUnit Testing for Elixir https://hexdocs.pm/exunit/ExUnit.html Code-Level Testing of Smalltalk Applications https://www.cs.ubc.ca/~murphy/stworkshop/28-7.html Agile Manifesto https://agilemanifesto.org/ Old Man Yells at Cloud https://i.kym-cdn.com/entries/icons/original/000/019/304/old.jpg TDD: Test Driven Development https://www.agilealliance.org/glossary/tdd/ Perl Programming Language https://www.perl.org/ Protractor Test Framework for Angular and AngularJS protractortest.org/#/ Waterfall Project Management https://business.adobe.com/blog/basics/waterfall CodeSync Leveling up at Bleacher Report A cautionary tale - PETER HASTIE https://www.youtube.com/watch?v=P4SzZCwB8B4 Mix ecto.dump https://hexdocs.pm/ectosql/Mix.Tasks.Ecto.Dump.html Apache JMeter Load Testing in Java https://jmeter.apache.org/ Pentest Tools Collection - Penetration Testing https://github.com/arch3rPro/PentestTools The Road to 2 Million Websocket Connections in Phoenix https://www.phoenixframework.org/blog/the-road-to-2-million-websocket-connections Donate to Miami Indians of Indiana https://www.miamiindians.org/take-action Joel Meador on Tumblr https://joelmeador.tumblr.com/ Special Guests: Charles Suggs and Joel Meador.

In this episode, we dive deep into the world of clean coding with none other than the master and pioneer of the field, Uncle Bob. We explore the nuances and the art behind writing effective and efficient scripts. This conversation covers the nitty-gritty of writing and editing scripts, from understanding how to break down large functions, to discussing principles like 'Single Responsibility Principle', 'Dependency Inversion Principle' and how to balance the 'DRY' (Don't Repeat Yourself) principles. Uncle Bob also shares valuable insights on testing, handling errors, naming conventions and how to work with different types of duplication in coding. He shares recommended resources and books that every coder should read. Chapters: 00:00 Introduction and Welcome 00:06 The Importance of Code Quality 00:29 Introducing Robert Martin (Uncle Bob) 01:39 Uncle Bob's Journey in Programming 02:34 Discussion on Functional Design and New Book 03:52 The Evolution of Software Development 04:28 Revisiting the Clean Code Book 04:49 The Impact of Hardware Changes on Software 06:13 The Evolution of Programming Languages 07:33 The Importance of Code Structure and Organization 09:07 The Impact of Microservices and Open Source 11:14 The Role of Modular Programming 22:07 The Importance of Naming in Code 26:31 The Role of Functions in Code 34:12 The Role of Switch Statements in Code 42:36 The Importance of Immutability 51:00 Dealing with Complex Steps in Programming 51:21 Implementing State Machines in Programming 51:46 The Pragmatic Approach to Programming 53:01 Understanding Error Handling in Programming 54:08 The Challenge of Exception Handling 57:27 The Importance of Log Messages in Debugging 01:03:05 The Dilemma of Code Duplication 01:05:51 The Intricacies of Error Handling 01:07:40 The Role of Abstraction in Programming 01:13:55 The Importance of Testing in Programming 01:19:43 The Challenges of Mocking in Testing 01:25:11 The Essence of Programming: Discipline, Ethics, and Standards Book Recommendations: Tidy First: https://www.oreilly.com/library/view/tidy-first/9781098151232/ Design Patterns: https://www.amazon.de/-/en/Erich-Gamma/dp/0201633612 Analysis Pattern: https://martinfowler.com/books/ap.html Structured Analysis and System Specification: https://www.amazon.de/-/en/Tom-Demarco/dp/0138543801 Fundamental Algorithms: https://www.amazon.com/Art-Computer-Programming-Vol-Fundamental/dp/0201896834 Sorting and Searching: https://www.amazon.de/-/en/Donald-Knuth/dp/0201896850 Structure and Interpretation of Computer Programs: https://web.mit.edu/6.001/6.037/sicp.pdf =============================================================================== For discount on the below courses: Appsync: https://appsyncmasterclass.com/?affiliateId=41c07a65-24c8-4499-af3c-b853a3495003 Testing serverless: https://testserverlessapps.com/?affiliateId=41c07a65-24c8-4499-af3c-b853a3495003 Production-Ready Serverless: https://productionreadyserverless.com/?affiliateId=41c07a65-24c8-4499-af3c-b853a3495003 Use the button, Add Discount and enter "geeknarrator" discount code to get 20% discount. =============================================================================== Follow me on Linkedin and Twitter: https://www.linkedin.com/in/kaivalyaapte/ and https://twitter.com/thegeeknarrator If you like this episode, please hit the like button and share it with your network. Also please subscribe if you haven't yet. Database internals series: https://youtu.be/yV_Zp0Mi3xs Popular playlists: Realtime streaming systems: https://www.youtube.com/playlist?list=PLL7QpTxsA4se-mAKKoVOs3VcaP71X_LA- Software Engineering: https://www.youtube.com/playlist?list=PLL7QpTxsA4sf6By03bot5BhKoMgxDUU17 Distributed systems and databases: https://www.youtube.com/playlist?list=PLL7QpTxsA4sfLDUnjBJXJGFhhz94jDd_d Modern databases: https://www.youtube.com/playlist?list=PLL7QpTxsA4scSeZAsCUXijtnfW5ARlrsN Stay Curios! Keep Learning!

If you don't already know Bob, he is a software engineer, instructor, and best-selling author. He is most recognized for developing numerous software design principles and for being a founder of the incredibly influential Agile Manifesto. Bob is the author of a number of Clean Code related books including his latest, Clean Agile: Back to Basics, where he reintroduces Agile values and principles for a new generation of programmers and nonprogrammers alike. In the past, Bob was also the editor-in-chief of C++ Report magazine and served as the first chairman of the Agile Alliance.   Topics of Discussion: [3:48] Why the term “clean” when it comes to software?  [5:16] Are people still writing “dirty” software?  [7:06] it is the developers job to maintain quality, and pretending to go fast by rushing is not a viable solution.  [9:54] Uncle Bob's upcoming book on the history of programmers.  [11:00] The first era of programmers may be the scribes of Egypt.  [15:00] How Uncle Bob went about organizing the book into different eras of programmers.  [18:10] A short backstory about Grace Hopper.  [23:33] Uncle Bob's other new book which is out now, Functional Design.  [24:54] Structure and Interpretation of Computer Programs  [28:37] Does functionality have a concise set of principles?  [33:11] Where are the shifts happening?  [34:01] The loss of Moore's Law.  [37:33] What will be the winning strategies as we prepare for a few years where things grow, but not as quickly as they have, and we sit on a plateau?  [40:51] Make it right, then you can make it fast.    Mentioned in this Episode: Clear Measure Way Architect Forum Software Engineer Forum Programming with Palermo — New Video Podcast! Email us at programming@palermo.net. Clear Measure, Inc. (Sponsor) .NET DevOps for Azure: A Developer's Guide to DevOps Architecture the Right Way, by Jeffrey Palermo — Available on Amazon! Jeffrey Palermo's Twitter — Follow to stay informed about future events!  Previous episode with Uncle Bob Functional Design  Clean Coders .NET Developer Apprentice - Texas Clean Agile    Want to Learn More? Visit AzureDevOps.Show for show notes and additional episodes.

- Disclaimers: 01:09 - Las premisas de Clean Code: 01:40 - Siempre habrá código: 02:03 - Los costos de un código desastroso: 17:00 - ¿Cómo se puede resolver el problema de código sucio?: 23:35 - ¿Qué es Clean Code?: 24:18 - ¿Por qué es importante Clean Code?: 25:17 - Las fortalezas de Clean Code: 30:55 - ¿Cómo aprender a escribir Clean Code?: 40:21 - Algunas consideraciones: 51:55 –––––––––––––––––––––––––––––– Para Contribuir PAYPAL : https://www.paypal.me/codetime Mercado Pago $100: https://mpago.la/1Zqo3G9 Mercado Pago $500: https://mpago.la/2MZ3oz3 Mercado Pago $1000: https://mpago.la/333qhPp –––––––––––––––––––––––––––––– Curso completo de desarrollo en Swift 4 desde cero https://www.udemy.com/curso-completo-de-swift-4-desde-cero/?couponCode=YOUTUBE_1 Curso de desarrollo de aplicaciones para iOS 11 desde cero https://www.udemy.com/desarrollo-de-aplicaciones-para-ios-11-desde-cero/?couponCode=YOUTUBE_1 –––––––––––––––––––––––––––––– Medios de contacto: Twitter / Telegram: @DavidGiordana Correo Electrónico: davidgiordana0@gmail.com Grupo en Telegram: https://t.me/joinchat/C-YEzBGu5Jh-mu8ejM2toA –––––––––––––––––––––––––––––– Canciones Utilizadas OP: Adventures by A Himitsu https://soundcloud.com/a-himitsu Creative Commons — Attribution 3.0 Unported— CC BY 3.0 Free Download / Stream: http://bit.ly/2Pj0MtT Music released by Argofox https://youtu.be/8BXNwnxaVQE Music promoted by Audio Library https://youtu.be/MkNeIUgNPQ8 ED: See You Tomorrow by GoSoundtrack http://www.gosoundtrack.com Creative Commons — Attribution 4.0 International — CC BY 4.0 Free Download / Stream: http://bit.ly/see-you-tomorrow Music promoted by Audio Library https://youtu.be/idlqqMHd0W4

- Presentación: 00:12 - Disclaimers: 01:45 Clean Code - Testing - Introducción al testing: 02:48 - Tests insuficientes: 08:41 - Usar herramientas de coverage: 17:11 - No saltear los tests triviales: 21:31 - Un test ignorado es una pregunta sobre una ambigüedad: 25:02 - Testear las condiciones borde: 31:32 - Testear exhaustivamente alrededor de los bugs: 38:04 - Los patrones de fallo revelan información: 45:48 - Los patrones de coverage pueden revelar información: 52:51 - Los tests deben correr rápido: 58:36 - Cierre: 1:06:52 –––––––––––––––––––––––––––––– Para Contribuir PAYPAL : https://www.paypal.me/codetime Mercado Pago $100: https://mpago.la/1Zqo3G9 Mercado Pago $500: https://mpago.la/2MZ3oz3 Mercado Pago $1000: https://mpago.la/333qhPp –––––––––––––––––––––––––––––– Curso completo de desarrollo en Swift 4 desde cero https://www.udemy.com/curso-completo-de-swift-4-desde-cero/?couponCode=YOUTUBE_1 Curso de desarrollo de aplicaciones para iOS 11 desde cero https://www.udemy.com/desarrollo-de-aplicaciones-para-ios-11-desde-cero/?couponCode=YOUTUBE_1 –––––––––––––––––––––––––––––– Medios de contacto: Twitter / Telegram: @DavidGiordana Correo Electrónico: davidgiordana0@gmail.com Grupo en Telegram: https://t.me/joinchat/C-YEzBGu5Jh-mu8ejM2toA –––––––––––––––––––––––––––––– Canciones Utilizadas OP: Adventures by A Himitsu https://soundcloud.com/a-himitsu Creative Commons — Attribution 3.0 Unported— CC BY 3.0 Free Download / Stream: http://bit.ly/2Pj0MtT Music released by Argofox https://youtu.be/8BXNwnxaVQE Music promoted by Audio Library https://youtu.be/MkNeIUgNPQ8 ED: See You Tomorrow by GoSoundtrack http://www.gosoundtrack.com Creative Commons — Attribution 4.0 International — CC BY 4.0 Free Download / Stream: http://bit.ly/see-you-tomorrow Music promoted by Audio Library https://youtu.be/idlqqMHd0W4

- Inicio: 00:00 - Charla pre podcast: 00:12 - Presentación: 13:08 - Disclaimers: 14:41 Clean Code - Testing - Introducción al testing: 15:44 - Tests insuficientes: 21:37 - Usar herramientas de coverage: 30:07 - No saltear los tests triviales: 34:27 - Un test ignorado es una pregunta sobre una ambigüedad: 37:58 - Testear las condiciones borde: 44:28 - Testear exhaustivamente alrededor de los bugs: 51:00 - Los patrones de fallo revelan información: 58:44 - Los patrones de coverage pueden revelar información: 1:05:47 - Los tests deben correr rápido: 1:11:32 - Charla post podcast: 1:19:48 - Cierre: 2:51:50 –––––––––––––––––––––––––––––– Para Contribuir PAYPAL : https://www.paypal.me/codetime Mercado Pago $100: https://mpago.la/1Zqo3G9 Mercado Pago $500: https://mpago.la/2MZ3oz3 Mercado Pago $1000: https://mpago.la/333qhPp –––––––––––––––––––––––––––––– Curso completo de desarrollo en Swift 4 desde cero https://www.udemy.com/curso-completo-de-swift-4-desde-cero/?couponCode=YOUTUBE_1 Curso de desarrollo de aplicaciones para iOS 11 desde cero https://www.udemy.com/desarrollo-de-aplicaciones-para-ios-11-desde-cero/?couponCode=YOUTUBE_1 –––––––––––––––––––––––––––––– Medios de contacto: Twitter / Telegram: @DavidGiordana Correo Electrónico: davidgiordana0@gmail.com Grupo en Telegram: https://t.me/joinchat/C-YEzBGu5Jh-mu8ejM2toA –––––––––––––––––––––––––––––– Canciones Utilizadas OP: Adventures by A Himitsu https://soundcloud.com/a-himitsu Creative Commons — Attribution 3.0 Unported— CC BY 3.0 Free Download / Stream: http://bit.ly/2Pj0MtT Music released by Argofox https://youtu.be/8BXNwnxaVQE Music promoted by Audio Library https://youtu.be/MkNeIUgNPQ8 ED: See You Tomorrow by GoSoundtrack http://www.gosoundtrack.com Creative Commons — Attribution 4.0 International — CC BY 4.0 Free Download / Stream: http://bit.ly/see-you-tomorrow Music promoted by Audio Library https://youtu.be/idlqqMHd0W4

In this conversation, Ben interviews Taylor Otwell, the creator of Laravel. They discuss everything from the age-old argument of tabs vs. spaces to the origins of Laravel and how Taylor has turned it into a thriving, sustainable business.Links:Laravel, the framework Taylor createdTuple, used by the Laravel team to collaboratesTakeawaysCoding preferences and philosophies can vary among developers and programming ecosystems.Maintaining backwards compatibility is important for frameworks with a large user base.Clean code can be subjective and depends on the specific needs and goals of a project.Testing is crucial for shipping software with confidence. When starting a new project, consider writing documentation first to iron out any potential issues and ensure a user-centric perspective.Focus on high-level testing, such as feature-level or controller-level tests, to gain confidence in the functionality of your code.Challenge assumptions and ask questions to improve the quality of your code and avoid unnecessary complexity.Believe in the potential of your project and raise your ambitions to achieve greater success.Building a business around open source can be a sustainable model if you create commercial products that complement and support the open source project.Chapters(00:00) - Tabs or Spaces? (08:00) - Shells (10:46) - Minimalism in Coding (17:24) - Stripe and Their API (22:41) - Aesthetics (25:09) - A Coding Hill You Would Die On (28:09) - Clean Code (33:38) - Testing (40:30) - Personal Involvement With Code (45:00) - Notes and Manifestos (49:09) - Skill Over Time (51:49) - Ian Landsman and Laravel (55:49) - Businesses Based on Open Source

- Presentación: 00:13 - Breve descripción de Clean Code: 00:39 - Disclaimers: 02:55 Clean Code - Nombres - Elegir nombres descriptivos: 04:08 - Elegir nombres apropiados al nivel de abstracción: 13:14 - Usar nomenclatura estándar cuando sea posible: 20:09 - Nombres no ambíguos: 25:36 - Usar nombres largos en grandes ámbitos: 28:28 - Evitar codificar información en nombres: 32:31 - Los nombres deberían describir los efectos laterales: 35:50 - Cierre: 43:45 –––––––––––––––––––––––––––––– Para Contribuir PAYPAL : https://www.paypal.me/codetime Mercado Pago $100: https://mpago.la/1Zqo3G9 Mercado Pago $500: https://mpago.la/2MZ3oz3 Mercado Pago $1000: https://mpago.la/333qhPp –––––––––––––––––––––––––––––– Curso completo de desarrollo en Swift 4 desde cero https://www.udemy.com/curso-completo-de-swift-4-desde-cero/?couponCode=YOUTUBE_1 Curso de desarrollo de aplicaciones para iOS 11 desde cero https://www.udemy.com/desarrollo-de-aplicaciones-para-ios-11-desde-cero/?couponCode=YOUTUBE_1 –––––––––––––––––––––––––––––– Medios de contacto: Twitter / Telegram: @DavidGiordana Correo Electrónico: davidgiordana0@gmail.com Grupo en Telegram: https://t.me/joinchat/C-YEzBGu5Jh-mu8ejM2toA –––––––––––––––––––––––––––––– Canciones Utilizadas OP: Adventures by A Himitsu https://soundcloud.com/a-himitsu Creative Commons — Attribution 3.0 Unported— CC BY 3.0 Free Download / Stream: http://bit.ly/2Pj0MtT Music released by Argofox https://youtu.be/8BXNwnxaVQE Music promoted by Audio Library https://youtu.be/MkNeIUgNPQ8 ED: See You Tomorrow by GoSoundtrack http://www.gosoundtrack.com Creative Commons — Attribution 4.0 International — CC BY 4.0 Free Download / Stream: http://bit.ly/see-you-tomorrow Music promoted by Audio Library https://youtu.be/idlqqMHd0W4

- Charla pre podcast: 00:13 - Presentación: 45:47 - Breve descripción de Clean Code: 46:13 - Disclaimers: 48:29 Clean Code - Nombres - Elegir nombres descriptivos: 49:42 - Elegir nombres apropiados al nivel de abstracción: 58:48 - Usar nomenclatura estándar cuando sea posible: 1:05:43 - Nombres no ambíguos: 1:11:10 - Usar nombres largos en grandes ámbitos: 1:14:02 - Evitar codificar información en nombres: 1:18:05 - Los nombres deberían describir los efectos laterales: 1:21:24 - Charla post podcast: 1:29:19 - Cierre: 2:13:40 –––––––––––––––––––––––––––––– Para Contribuir PAYPAL : https://www.paypal.me/codetime Mercado Pago $100: https://mpago.la/1Zqo3G9 Mercado Pago $500: https://mpago.la/2MZ3oz3 Mercado Pago $1000: https://mpago.la/333qhPp –––––––––––––––––––––––––––––– Curso completo de desarrollo en Swift 4 desde cero https://www.udemy.com/curso-completo-de-swift-4-desde-cero/?couponCode=YOUTUBE_1 Curso de desarrollo de aplicaciones para iOS 11 desde cero https://www.udemy.com/desarrollo-de-aplicaciones-para-ios-11-desde-cero/?couponCode=YOUTUBE_1 –––––––––––––––––––––––––––––– Medios de contacto: Twitter / Telegram: @DavidGiordana Correo Electrónico: davidgiordana0@gmail.com Grupo en Telegram: https://t.me/joinchat/C-YEzBGu5Jh-mu8ejM2toA –––––––––––––––––––––––––––––– Canciones Utilizadas OP: Adventures by A Himitsu https://soundcloud.com/a-himitsu Creative Commons — Attribution 3.0 Unported— CC BY 3.0 Free Download / Stream: http://bit.ly/2Pj0MtT Music released by Argofox https://youtu.be/8BXNwnxaVQE Music promoted by Audio Library https://youtu.be/MkNeIUgNPQ8 ED: See You Tomorrow by GoSoundtrack http://www.gosoundtrack.com Creative Commons — Attribution 4.0 International — CC BY 4.0 Free Download / Stream: http://bit.ly/see-you-tomorrow Music promoted by Audio Library https://youtu.be/idlqqMHd0W4

- Breve descripción de Clean Code: 00:31 - Disclaimers: 02:02 Clean Code - Aspectos Generales PT 8 - Las funcione solo deberían descender un solo nivel de abstracción: 05:13 * Incluye anécdota de ECG - Mantener datos configurables en niveles altos: 58:00 - Evitar la navegación transitiva: 1:09:24 - Cierre: 1:16:25 –––––––––––––––––––––––––––––– Para Contribuir PAYPAL : https://www.paypal.me/codetime Mercado Pago $100: https://mpago.la/1Zqo3G9 Mercado Pago $500: https://mpago.la/2MZ3oz3 Mercado Pago $1000: https://mpago.la/333qhPp –––––––––––––––––––––––––––––– Curso completo de desarrollo en Swift 4 desde cero https://www.udemy.com/curso-completo-de-swift-4-desde-cero/?couponCode=YOUTUBE_1 Curso de desarrollo de aplicaciones para iOS 11 desde cero https://www.udemy.com/desarrollo-de-aplicaciones-para-ios-11-desde-cero/?couponCode=YOUTUBE_1 –––––––––––––––––––––––––––––– Medios de contacto: Twitter / Telegram: @DavidGiordana Correo Electrónico: davidgiordana0@gmail.com Grupo en Telegram: https://t.me/joinchat/C-YEzBGu5Jh-mu8ejM2toA –––––––––––––––––––––––––––––– Canciones Utilizadas OP: Adventures by A Himitsu https://soundcloud.com/a-himitsu Creative Commons — Attribution 3.0 Unported— CC BY 3.0 Free Download / Stream: http://bit.ly/2Pj0MtT Music released by Argofox https://youtu.be/8BXNwnxaVQE Music promoted by Audio Library https://youtu.be/MkNeIUgNPQ8 ED: See You Tomorrow by GoSoundtrack http://www.gosoundtrack.com Creative Commons — Attribution 4.0 International — CC BY 4.0 Free Download / Stream: http://bit.ly/see-you-tomorrow Music promoted by Audio Library https://youtu.be/idlqqMHd0W4

- Charla pre podcast: 0:11 - Presentación: 40:34 - Breve descripción de Clean Code: 40:54 - Disclaimers: 42:25 Clean Code - Aspectos Generales PT 8 - Las funcione solo deberían descender un solo nivel de abstracción: 45:36 * Incluye anécdota de ECG - Mantener datos configurables en niveles altos: 1:38:23 - Evitar la navegación transitiva: 1:49:47 - Charla post podcast: 1:56:48 - Cierre: 2:28:26 –––––––––––––––––––––––––––––– Para Contribuir PAYPAL : https://www.paypal.me/codetime Mercado Pago $100: https://mpago.la/1Zqo3G9 Mercado Pago $500: https://mpago.la/2MZ3oz3 Mercado Pago $1000: https://mpago.la/333qhPp –––––––––––––––––––––––––––––– Curso completo de desarrollo en Swift 4 desde cero https://www.udemy.com/curso-completo-de-swift-4-desde-cero/?couponCode=YOUTUBE_1 Curso de desarrollo de aplicaciones para iOS 11 desde cero https://www.udemy.com/desarrollo-de-aplicaciones-para-ios-11-desde-cero/?couponCode=YOUTUBE_1 –––––––––––––––––––––––––––––– Medios de contacto: Twitter / Telegram: @DavidGiordana Correo Electrónico: davidgiordana0@gmail.com Grupo en Telegram: https://t.me/joinchat/C-YEzBGu5Jh-mu8ejM2toA –––––––––––––––––––––––––––––– Canciones Utilizadas OP: Adventures by A Himitsu https://soundcloud.com/a-himitsu Creative Commons — Attribution 3.0 Unported— CC BY 3.0 Free Download / Stream: http://bit.ly/2Pj0MtT Music released by Argofox https://youtu.be/8BXNwnxaVQE Music promoted by Audio Library https://youtu.be/MkNeIUgNPQ8 ED: See You Tomorrow by GoSoundtrack http://www.gosoundtrack.com Creative Commons — Attribution 4.0 International — CC BY 4.0 Free Download / Stream: http://bit.ly/see-you-tomorrow Music promoted by Audio Library https://youtu.be/idlqqMHd0W4

On today's episode, Elixir Wizards Owen Bickford and Dan Ivovich compare notes on building web applications with Elixir and the Phoenix Framework versus Ruby on Rails. They discuss the history of both frameworks, key differences in architecture and approach, and deciding which programming language to use when starting a project. Both Phoenix and Rails are robust frameworks that enable developers to build high-quality web apps—Phoenix leverages functional programming in Elixir and Erlang's networking for real-time communication. Rails follows object-oriented principles and has a vast ecosystem of plug-ins. For data-heavy CRUD apps, Phoenix's immutable data pipelines provide some advantages. Developers can build great web apps with either Phoenix or Rails. Phoenix may have a slight edge for new projects based on its functional approach, built-in real-time features like LiveView, and ability to scale efficiently. But, choosing the right tech stack depends heavily on the app's specific requirements and the team's existing skills. Topics discussed in this episode: History and evolution of Phoenix Framework and Ruby on Rails Default project structure and code organization preferences in each framework Comparing object-oriented vs functional programming paradigms CRUD app development and interaction with databases Live reloading capabilities in Phoenix LiveView vs Rails Turbolinks Leveraging WebSockets for real-time UI updates Testing frameworks like RSpec, Cucumber, Wallaby, and Capybara Dependency management and size of standard libraries Scalability and distribution across nodes Readability and approachability of object-oriented code Immutability and data pipelines in functional programming Types, specs, and static analysis with Dialyzer Monkey patching in Ruby vs extensible core language in Elixir Factors to consider when choosing between frameworks Experience training new developers on Phoenix and Rails Community influences on coding styles Real-world project examples and refactoring approaches Deployment and dev ops differences Popularity and adoption curves of both frameworks Ongoing research into improving Phoenix and Rails Links Mentioned in this Episode: SmartLogic.io (https://smartlogic.io/) Dan's LinkedIn (https://www.linkedin.com/in/divovich/) Owen's LinkedIn (https://www.linkedin.com/in/owen-bickford-8b6b1523a/) Ruby https://www.ruby-lang.org/en/ Rails https://rubyonrails.org/ Sams Teach Yourself Ruby in 21 Days (https://www.overdrive.com/media/56304/sams-teach-yourself-ruby-in-21-days) Learn Ruby in 7 Days (https://www.thriftbooks.com/w/learn-ruby-in-7-days---color-print---ruby-tutorial-for-guaranteed-quick-learning-ruby-guide-with-many-practical-examples-this-ruby-programming-book--to-build-real-life-software-projects/18539364/#edition=19727339&idiq=25678249) Build Your Own Ruby on Rails Web Applications (https://www.thriftbooks.com/w/build-your-own-ruby-on-rails-web-applications_patrick-lenz/725256/item/2315989/?utm_source=google&utm_medium=cpc&utm_campaign=low_vol_backlist_standard_shopping_customer_acquisition&utm_adgroup=&utm_term=&utm_content=593118743925&gad_source=1&gclid=CjwKCAiA1MCrBhAoEiwAC2d64aQyFawuU3znN0VFgGyjR0I-0vrXlseIvht0QPOqx4DjKjdpgjCMZhoC6PcQAvD_BwE#idiq=2315989&edition=3380836) Django https://github.com/django Sidekiq https://github.com/sidekiq Kafka https://kafka.apache.org/ Phoenix Framework https://www.phoenixframework.org/ Phoenix LiveView https://hexdocs.pm/phoenixliveview/Phoenix.LiveView.html#content Flask https://flask.palletsprojects.com/en/3.0.x/ WebSockets API https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_API WebSocket connection for Phoenix https://github.com/phoenixframework/websock Morph Dom https://github.com/patrick-steele-idem/morphdom Turbolinks https://github.com/turbolinks Ecto https://github.com/elixir-ecto Capybara Testing Framework https://teamcapybara.github.io/capybara/ Wallaby Testing Framework https://wallabyjs.com/ Cucumber Testing Framework https://cucumber.io/ RSpec https://rspec.info/

- Disclaimers: 02:28 Clean Code - Aspectos Generales PT 7 - Encapsular opcionales: 03:10 - Evitar negar condicionales: 11:59 - Las funciones deberían hacer una sola cosa: 16:37 - Evitar el acoplamiento temporal implícito: 21:33 - No ser arbitrarios: 32:02 - Encapsular condiciones borde: 49:24 - Cierre: 58:52 –––––––––––––––––––––––––––––– Para Contribuir PAYPAL : https://www.paypal.me/codetime Mercado Pago $100: https://mpago.la/1Zqo3G9 Mercado Pago $500: https://mpago.la/2MZ3oz3 Mercado Pago $1000: https://mpago.la/333qhPp –––––––––––––––––––––––––––––– Curso completo de desarrollo en Swift 4 desde cero https://www.udemy.com/curso-completo-de-swift-4-desde-cero/?couponCode=YOUTUBE_1 Curso de desarrollo de aplicaciones para iOS 11 desde cero https://www.udemy.com/desarrollo-de-aplicaciones-para-ios-11-desde-cero/?couponCode=YOUTUBE_1 –––––––––––––––––––––––––––––– Medios de contacto: Twitter / Telegram: @DavidGiordana Correo Electrónico: davidgiordana0@gmail.com Grupo en Telegram: https://t.me/joinchat/C-YEzBGu5Jh-mu8ejM2toA –––––––––––––––––––––––––––––– Canciones Utilizadas OP: Adventures by A Himitsu https://soundcloud.com/a-himitsu Creative Commons — Attribution 3.0 Unported— CC BY 3.0 Free Download / Stream: http://bit.ly/2Pj0MtT Music released by Argofox https://youtu.be/8BXNwnxaVQE Music promoted by Audio Library https://youtu.be/MkNeIUgNPQ8 ED: See You Tomorrow by GoSoundtrack http://www.gosoundtrack.com Creative Commons — Attribution 4.0 International — CC BY 4.0 Free Download / Stream: http://bit.ly/see-you-tomorrow Music promoted by Audio Library https://youtu.be/idlqqMHd0W4

- Charla Pre Podcast: 00:13 - Comienzo del podcast: 48:09 - Disclaimer: 51:56 Clean Code - Aspectos Generales PT 6 - Preferir polimorfismo sobre if-else y switch-case: 52:55 - Seguir las convenciones estandar: 1:10:26 - Reemplazar números mágicos por constantes nombradas: 1:21:00 - Ser precisos: 1:28:28 - Estructura sobre convenciones: 1:36:00 - Charla Post Podcast: 1:42:49 - Cierre: 1:57:34 –––––––––––––––––––––––––––––– Para Contribuir PAYPAL : https://www.paypal.me/codetime Mercado Pago $100: https://mpago.la/1Zqo3G9 Mercado Pago $500: https://mpago.la/2MZ3oz3 Mercado Pago $1000: https://mpago.la/333qhPp –––––––––––––––––––––––––––––– Curso completo de desarrollo en Swift 4 desde cero https://www.udemy.com/curso-completo-de-swift-4-desde-cero/?couponCode=YOUTUBE_1 Curso de desarrollo de aplicaciones para iOS 11 desde cero https://www.udemy.com/desarrollo-de-aplicaciones-para-ios-11-desde-cero/?couponCode=YOUTUBE_1 –––––––––––––––––––––––––––––– Medios de contacto: Twitter / Telegram: @DavidGiordana Correo Electrónico: davidgiordana0@gmail.com Grupo en Telegram: https://t.me/joinchat/C-YEzBGu5Jh-mu8ejM2toA –––––––––––––––––––––––––––––– Canciones Utilizadas OP: Adventures by A Himitsu https://soundcloud.com/a-himitsu Creative Commons — Attribution 3.0 Unported— CC BY 3.0 Free Download / Stream: http://bit.ly/2Pj0MtT Music released by Argofox https://youtu.be/8BXNwnxaVQE Music promoted by Audio Library https://youtu.be/MkNeIUgNPQ8 ED: See You Tomorrow by GoSoundtrack http://www.gosoundtrack.com Creative Commons — Attribution 4.0 International — CC BY 4.0 Free Download / Stream: http://bit.ly/see-you-tomorrow Music promoted by Audio Library https://youtu.be/idlqqMHd0W4

- Comienzo del podcast: 00:13 - Disclaimer: 04:00 Clean Code - Aspectos Generales PT 6 - Preferir polimorfismo sobre if-else y switch-case: 04:59 - Seguir las convenciones estandar: 22:30 - Reemplazar números mágicos por constantes nombradas: 33:04 - Ser precisos: 40:32 - Estructura sobre convenciones: 48:04 - Cierre: 54:53 –––––––––––––––––––––––––––––– Para Contribuir PAYPAL : https://www.paypal.me/codetime Mercado Pago $100: https://mpago.la/1Zqo3G9 Mercado Pago $500: https://mpago.la/2MZ3oz3 Mercado Pago $1000: https://mpago.la/333qhPp –––––––––––––––––––––––––––––– Curso completo de desarrollo en Swift 4 desde cero https://www.udemy.com/curso-completo-de-swift-4-desde-cero/?couponCode=YOUTUBE_1 Curso de desarrollo de aplicaciones para iOS 11 desde cero https://www.udemy.com/desarrollo-de-aplicaciones-para-ios-11-desde-cero/?couponCode=YOUTUBE_1 –––––––––––––––––––––––––––––– Medios de contacto: Twitter / Telegram: @DavidGiordana Correo Electrónico: davidgiordana0@gmail.com Grupo en Telegram: https://t.me/joinchat/C-YEzBGu5Jh-mu8ejM2toA –––––––––––––––––––––––––––––– Canciones Utilizadas OP: Adventures by A Himitsu https://soundcloud.com/a-himitsu Creative Commons — Attribution 3.0 Unported— CC BY 3.0 Free Download / Stream: http://bit.ly/2Pj0MtT Music released by Argofox https://youtu.be/8BXNwnxaVQE Music promoted by Audio Library https://youtu.be/MkNeIUgNPQ8 ED: See You Tomorrow by GoSoundtrack http://www.gosoundtrack.com Creative Commons — Attribution 4.0 International — CC BY 4.0 Free Download / Stream: http://bit.ly/see-you-tomorrow Music promoted by Audio Library https://youtu.be/idlqqMHd0W4

En este episodio hablaremos un poco sobre Clean Code y Clean Architecture, considerando qué tanto debemos de implementarlo en nuestros proyectos. --- Support this podcast: https://podcasters.spotify.com/pod/show/fernando-her85/support

- Charla Pre Podcast: 00:11 - Comienzo del podcast: 15:52 - Disclaimer: 18:33 Clean Code - Aspectos Generales PT 5 - Responsabilidad mal ubicada: 19:37 - Funciones estáticas inadecuadas: 30:53 - Uso de variables explicativas: 42:15 - Los nombres de las funciones beben explicar lo que hacen: 46:14 - Entender el algoritmo: 50:17 - Argumentos Selectores: 1:11:26 - Convertir dependencias lógicas en dependencias físicas: 56:46 - Charla Post Podcast: 1:03:17 - Cierre: 1:57:08 –––––––––––––––––––––––––––––– Para Contribuir PAYPAL : https://www.paypal.me/codetime Mercado Pago $100: https://mpago.la/1Zqo3G9 Mercado Pago $500: https://mpago.la/2MZ3oz3 Mercado Pago $1000: https://mpago.la/333qhPp –––––––––––––––––––––––––––––– Curso completo de desarrollo en Swift 4 desde cero https://www.udemy.com/curso-completo-de-swift-4-desde-cero/?couponCode=YOUTUBE_1 Curso de desarrollo de aplicaciones para iOS 11 desde cero https://www.udemy.com/desarrollo-de-aplicaciones-para-ios-11-desde-cero/?couponCode=YOUTUBE_1 –––––––––––––––––––––––––––––– Medios de contacto: Twitter / Telegram: @DavidGiordana Correo Electrónico: davidgiordana0@gmail.com Grupo en Telegram: https://t.me/joinchat/C-YEzBGu5Jh-mu8ejM2toA –––––––––––––––––––––––––––––– Canciones Utilizadas OP: Adventures by A Himitsu https://soundcloud.com/a-himitsu Creative Commons — Attribution 3.0 Unported— CC BY 3.0 Free Download / Stream: http://bit.ly/2Pj0MtT Music released by Argofox https://youtu.be/8BXNwnxaVQE Music promoted by Audio Library https://youtu.be/MkNeIUgNPQ8 ED: See You Tomorrow by GoSoundtrack http://www.gosoundtrack.com Creative Commons — Attribution 4.0 International — CC BY 4.0 Free Download / Stream: http://bit.ly/see-you-tomorrow Music promoted by Audio Library https://youtu.be/idlqqMHd0W4

- Comienzo del podcast: 00:11 - Disclaimer: 02:52 Clean Code - Aspectos Generales PT 5 - Responsabilidad mal ubicada: 03:56 - Funciones estáticas inadecuadas: 15:12 - Uso de variables explicativas: 26:34 - Los nombres de las funciones beben explicar lo que hacen: 30:33 - Entender el algoritmo: 34:36 - Argumentos Selectores: 55:45 - Convertir dependencias lógicas en dependencias físicas: 41:05 - Cierre: 47:36 –––––––––––––––––––––––––––––– Para Contribuir PAYPAL : https://www.paypal.me/codetime Mercado Pago $100: https://mpago.la/1Zqo3G9 Mercado Pago $500: https://mpago.la/2MZ3oz3 Mercado Pago $1000: https://mpago.la/333qhPp –––––––––––––––––––––––––––––– Curso completo de desarrollo en Swift 4 desde cero https://www.udemy.com/curso-completo-de-swift-4-desde-cero/?couponCode=YOUTUBE_1 Curso de desarrollo de aplicaciones para iOS 11 desde cero https://www.udemy.com/desarrollo-de-aplicaciones-para-ios-11-desde-cero/?couponCode=YOUTUBE_1 –––––––––––––––––––––––––––––– Medios de contacto: Twitter / Telegram: @DavidGiordana Correo Electrónico: davidgiordana0@gmail.com Grupo en Telegram: https://t.me/joinchat/C-YEzBGu5Jh-mu8ejM2toA –––––––––––––––––––––––––––––– Canciones Utilizadas OP: Adventures by A Himitsu https://soundcloud.com/a-himitsu Creative Commons — Attribution 3.0 Unported— CC BY 3.0 Free Download / Stream: http://bit.ly/2Pj0MtT Music released by Argofox https://youtu.be/8BXNwnxaVQE Music promoted by Audio Library https://youtu.be/MkNeIUgNPQ8 ED: See You Tomorrow by GoSoundtrack http://www.gosoundtrack.com Creative Commons — Attribution 4.0 International — CC BY 4.0 Free Download / Stream: http://bit.ly/see-you-tomorrow Music promoted by Audio Library https://youtu.be/idlqqMHd0W4

- Comienzo del podcast: 00:13 - Disclaimer: 00:58 Clean Code - Aspectos Generales PT 4 - Espaciado Vertical: 03:50 - Inconsistencias: 10:34 - Desorden: 16:15 - Acoplamiento Vertical: 19:35 - Envidia de características: 25:41 - Argumentos Selectores: 33:42 - No oscurecer la intención: 40:32 - Cierre: 44:32 –––––––––––––––––––––––––––––– Para Contribuir PAYPAL : https://www.paypal.me/codetime Mercado Pago $100: https://mpago.la/1Zqo3G9 Mercado Pago $500: https://mpago.la/2MZ3oz3 Mercado Pago $1000: https://mpago.la/333qhPp –––––––––––––––––––––––––––––– Curso completo de desarrollo en Swift 4 desde cero https://www.udemy.com/curso-completo-de-swift-4-desde-cero/?couponCode=YOUTUBE_1 Curso de desarrollo de aplicaciones para iOS 11 desde cero https://www.udemy.com/desarrollo-de-aplicaciones-para-ios-11-desde-cero/?couponCode=YOUTUBE_1 –––––––––––––––––––––––––––––– Medios de contacto: Twitter / Telegram: @DavidGiordana Correo Electrónico: davidgiordana0@gmail.com Grupo en Telegram: https://t.me/joinchat/C-YEzBGu5Jh-mu8ejM2toA –––––––––––––––––––––––––––––– Canciones Utilizadas OP: Adventures by A Himitsu https://soundcloud.com/a-himitsu Creative Commons — Attribution 3.0 Unported— CC BY 3.0 Free Download / Stream: http://bit.ly/2Pj0MtT Music released by Argofox https://youtu.be/8BXNwnxaVQE Music promoted by Audio Library https://youtu.be/MkNeIUgNPQ8 ED: See You Tomorrow by GoSoundtrack http://www.gosoundtrack.com Creative Commons — Attribution 4.0 International — CC BY 4.0 Free Download / Stream: http://bit.ly/see-you-tomorrow Music promoted by Audio Library https://youtu.be/idlqqMHd0W4

- Charla Pre Podcast: 00:13 - Comienzo del podcast: 37:57 - Disclaimer: 38:42 Clean Code - Aspectos Generales PT 4 - Espaciado Vertical: 41:34 - Inconsistencias: 48:18 - Desorden: 53:59 - Acoplamiento Vertical: 57:19 - Envidia de características: 1:03:25 - Argumentos Selectores: 1:11:26 - No oscurecer la intención: 1:18:16 - Charla Post Podcast: 1:22:16 - Cierre: 2:47:33 –––––––––––––––––––––––––––––– Para Contribuir PAYPAL : https://www.paypal.me/codetime Mercado Pago $100: https://mpago.la/1Zqo3G9 Mercado Pago $500: https://mpago.la/2MZ3oz3 Mercado Pago $1000: https://mpago.la/333qhPp –––––––––––––––––––––––––––––– Curso completo de desarrollo en Swift 4 desde cero https://www.udemy.com/curso-completo-de-swift-4-desde-cero/?couponCode=YOUTUBE_1 Curso de desarrollo de aplicaciones para iOS 11 desde cero https://www.udemy.com/desarrollo-de-aplicaciones-para-ios-11-desde-cero/?couponCode=YOUTUBE_1 –––––––––––––––––––––––––––––– Medios de contacto: Twitter / Telegram: @DavidGiordana Correo Electrónico: davidgiordana0@gmail.com Grupo en Telegram: https://t.me/joinchat/C-YEzBGu5Jh-mu8ejM2toA –––––––––––––––––––––––––––––– Canciones Utilizadas OP: Adventures by A Himitsu https://soundcloud.com/a-himitsu Creative Commons — Attribution 3.0 Unported— CC BY 3.0 Free Download / Stream: http://bit.ly/2Pj0MtT Music released by Argofox https://youtu.be/8BXNwnxaVQE Music promoted by Audio Library https://youtu.be/MkNeIUgNPQ8 ED: See You Tomorrow by GoSoundtrack http://www.gosoundtrack.com Creative Commons — Attribution 4.0 International — CC BY 4.0 Free Download / Stream: http://bit.ly/see-you-tomorrow Music promoted by Audio Library https://youtu.be/idlqqMHd0W4

- Recapitulación de episodios anteriores: 00:52 - Disclaimers: 05:03 + Aspectos Generales PT 3: - Clases base dependiendo de sus derivadas: 06:19 - Demasiada información: 28:19 - Código muerto: 50:42 - Cierre: 1:05:57 –––––––––––––––––––––––––––––– Para Contribuir PAYPAL : https://www.paypal.me/codetime Mercado Pago $100: https://mpago.la/1Zqo3G9 Mercado Pago $500: https://mpago.la/2MZ3oz3 Mercado Pago $1000: https://mpago.la/333qhPp –––––––––––––––––––––––––––––– Curso completo de desarrollo en Swift 4 desde cero https://www.udemy.com/curso-completo-de-swift-4-desde-cero/?couponCode=YOUTUBE_1 Curso de desarrollo de aplicaciones para iOS 11 desde cero https://www.udemy.com/desarrollo-de-aplicaciones-para-ios-11-desde-cero/?couponCode=YOUTUBE_1 –––––––––––––––––––––––––––––– Medios de contacto: Twitter / Telegram: @DavidGiordana Correo Electrónico: davidgiordana0@gmail.com Grupo en Telegram: https://t.me/joinchat/C-YEzBGu5Jh-mu8ejM2toA –––––––––––––––––––––––––––––– Canciones Utilizadas OP: Adventures by A Himitsu https://soundcloud.com/a-himitsu Creative Commons — Attribution 3.0 Unported— CC BY 3.0 Free Download / Stream: http://bit.ly/2Pj0MtT Music released by Argofox https://youtu.be/8BXNwnxaVQE Music promoted by Audio Library https://youtu.be/MkNeIUgNPQ8 ED: See You Tomorrow by GoSoundtrack http://www.gosoundtrack.com Creative Commons — Attribution 4.0 International — CC BY 4.0 Free Download / Stream: http://bit.ly/see-you-tomorrow Music promoted by Audio Library https://youtu.be/idlqqMHd0W4

- Charla pre podcast: 00:13 - Recapitulación de episodios anteriores: 18:42 - Disclaimers: 22:53 + Aspectos Generales PT 3: - Clases base dependiendo de sus derivadas: 24:09 - Demasiada información: 46:09 - Código muerto: 1:08:32 - Charla post podcast: 1:23:47 - Cierre: 1:29:03 –––––––––––––––––––––––––––––– Para Contribuir PAYPAL : https://www.paypal.me/codetime Mercado Pago $100: https://mpago.la/1Zqo3G9 Mercado Pago $500: https://mpago.la/2MZ3oz3 Mercado Pago $1000: https://mpago.la/333qhPp –––––––––––––––––––––––––––––– Curso completo de desarrollo en Swift 4 desde cero https://www.udemy.com/curso-completo-de-swift-4-desde-cero/?couponCode=YOUTUBE_1 Curso de desarrollo de aplicaciones para iOS 11 desde cero https://www.udemy.com/desarrollo-de-aplicaciones-para-ios-11-desde-cero/?couponCode=YOUTUBE_1 –––––––––––––––––––––––––––––– Medios de contacto: Twitter / Telegram: @DavidGiordana Correo Electrónico: davidgiordana0@gmail.com Grupo en Telegram: https://t.me/joinchat/C-YEzBGu5Jh-mu8ejM2toA –––––––––––––––––––––––––––––– Canciones Utilizadas OP: Adventures by A Himitsu https://soundcloud.com/a-himitsu Creative Commons — Attribution 3.0 Unported— CC BY 3.0 Free Download / Stream: http://bit.ly/2Pj0MtT Music released by Argofox https://youtu.be/8BXNwnxaVQE Music promoted by Audio Library https://youtu.be/MkNeIUgNPQ8 ED: See You Tomorrow by GoSoundtrack http://www.gosoundtrack.com Creative Commons — Attribution 4.0 International — CC BY 4.0 Free Download / Stream: http://bit.ly/see-you-tomorrow Music promoted by Audio Library https://youtu.be/idlqqMHd0W4

کد تمیز - فرمت‌بندی (بخش دوم: فرمت‌بندی عمودی)Clean Code - Vertical Formattingدر این ویدیو، به ادامه بررسی اصول فرمت‌بندی در کد تمیز می‌پردازیم و به مورد دوم، یعنی "فرمت‌بندی عمودی" می‌پردازیم. اصل فرمت‌بندی به عنوان یکی از جنبه‌های مهم در نگهداری کد تمیز و قابل درک است.در این بخش، توضیح می‌دهیم که چرا فرمت‌بندی عمودی به تازگی اهمیت بیشتری پیدا کرده و چگونه از طریق ترتیب مناسب خطوط کد می‌توان به قابلیت خوانایی و درک بهتر کد کمک کرد.ما انواع الگوهای فرمت‌بندی عمودی را با مثال‌های عملی نشان می‌دهیم. همچنین، به تأثیر این نوع فرمت‌بندی بر قابلیت گسترش و تغییر در کد و همچنین ارتباط آن با اصول دیگر کدنویسی می‌پردازیم.پیشنهاد می‌کنیم این ویدیو را با دقت تماشا کنید تا بتوانید با اصول و مهارت‌های فرمت‌بندی عمودی آشنا شده و در کدنویسی‌های خود از آن‌ها بهره‌برداری کنید.---------------------------------------------------------------لینک کانال در سایر شبکه های اجتماعیYouTube:https://www.youtube.com/c/Ardiland1---------------------------------------------------------------Telegram:https://t.me/ardiland_tm---------------------------------------------------------------Instagram:https://www.instagram.com/ardiland_ig/---------------------------------------------------------------Twitter:https://twitter.com/Ardiland3---------------------------------------------------------------GitHub:https://github.com/ardalanebrahimi---------------------------------------------------------------LinkedIn:https://www.linkedin.com/in/ardalan-ebrahimi---------------------------------------------------------------

Casey Muratori caused some strong reactions with a blog post and an associated video in which he went through an example from the “Clean Code” book by Robert Martin to demonstrate the negative impact that clean code practices can have on performance. In this episode, he joins SE Radio's Giovanni Asproni to talk about the potential trade-offs between performance and the qualities that make for maintainable code, these qualities being the main focus of Clean Code. Brought to you by IEEE Computer Society and IEEE Software magazine.

- Recapitulación Clean Code: 00:22 - Disclaimers: 03:09 - Generalidades: - Medidas de seguridad anuladas: 04:23 - Duplicación: 14:36 - Código en el nivel de abstracción incorrecto: 35:50 - Cierre: 55:03 –––––––––––––––––––––––––––––– Para Contribuir PAYPAL : https://www.paypal.me/codetime Mercado Pago $100: https://mpago.la/1Zqo3G9 Mercado Pago $500: https://mpago.la/2MZ3oz3 Mercado Pago $1000: https://mpago.la/333qhPp –––––––––––––––––––––––––––––– Curso completo de desarrollo en Swift 4 desde cero https://www.udemy.com/curso-completo-de-swift-4-desde-cero/?couponCode=YOUTUBE_1 Curso de desarrollo de aplicaciones para iOS 11 desde cero https://www.udemy.com/desarrollo-de-aplicaciones-para-ios-11-desde-cero/?couponCode=YOUTUBE_1 –––––––––––––––––––––––––––––– Medios de contacto: Twitter / Telegram: @DavidGiordana Correo Electrónico: davidgiordana0@gmail.com Grupo en Telegram: https://t.me/joinchat/C-YEzBGu5Jh-mu8ejM2toA –––––––––––––––––––––––––––––– Canciones Utilizadas OP: Adventures by A Himitsu https://soundcloud.com/a-himitsu Creative Commons — Attribution 3.0 Unported— CC BY 3.0 Free Download / Stream: http://bit.ly/2Pj0MtT Music released by Argofox https://youtu.be/8BXNwnxaVQE Music promoted by Audio Library https://youtu.be/MkNeIUgNPQ8 ED: See You Tomorrow by GoSoundtrack http://www.gosoundtrack.com Creative Commons — Attribution 4.0 International — CC BY 4.0 Free Download / Stream: http://bit.ly/see-you-tomorrow Music promoted by Audio Library https://youtu.be/idlqqMHd0W4

- Charla pre podcast: 00:13 - Comienzo del podcast: 30:10 - Recapitulación Clean Code: 30:19 - Disclaimers: 33:06 - Generalidades: - Medidas de seguridad anuladas: 34:20 - Duplicación: 44:33 - Código en el nivel de abstracción incorrecto: 1:05:47 - Charla post podcast: 1:25:00 - Cierre: 1:29:07 –––––––––––––––––––––––––––––– Para Contribuir PAYPAL : https://www.paypal.me/codetime Mercado Pago $100: https://mpago.la/1Zqo3G9 Mercado Pago $500: https://mpago.la/2MZ3oz3 Mercado Pago $1000: https://mpago.la/333qhPp –––––––––––––––––––––––––––––– Curso completo de desarrollo en Swift 4 desde cero https://www.udemy.com/curso-completo-de-swift-4-desde-cero/?couponCode=YOUTUBE_1 Curso de desarrollo de aplicaciones para iOS 11 desde cero https://www.udemy.com/desarrollo-de-aplicaciones-para-ios-11-desde-cero/?couponCode=YOUTUBE_1 –––––––––––––––––––––––––––––– Medios de contacto: Twitter / Telegram: @DavidGiordana Correo Electrónico: davidgiordana0@gmail.com Grupo en Telegram: https://t.me/joinchat/C-YEzBGu5Jh-mu8ejM2toA –––––––––––––––––––––––––––––– Canciones Utilizadas OP: Adventures by A Himitsu https://soundcloud.com/a-himitsu Creative Commons — Attribution 3.0 Unported— CC BY 3.0 Free Download / Stream: http://bit.ly/2Pj0MtT Music released by Argofox https://youtu.be/8BXNwnxaVQE Music promoted by Audio Library https://youtu.be/MkNeIUgNPQ8 ED: See You Tomorrow by GoSoundtrack http://www.gosoundtrack.com Creative Commons — Attribution 4.0 International — CC BY 4.0 Free Download / Stream: http://bit.ly/see-you-tomorrow Music promoted by Audio Library https://youtu.be/idlqqMHd0W4

- Pre podcast: 00:13 - Respondiendo comentario de episodio anterior: 01:28 - Comienzo del podcast: 17:40 - Disclaimers: 20:49 - Recapitulación: 23:12 - Funciones: - Funciones con demasiados argumentos: 24:48 - Argumentos de salida: 37:25 - Argumentos bandera: 43:38 - Funciones muertas: 50:08 - Generalidades: - Múltiples lenguajes en un solo archivo: 56:12 - Comportamiento obvio no implementado: 1:01:36 - Comportamiento incorrecto en condiciones borde: 1:10:53 - Charla post podcast: 1:22:45 - Cierre: 1:42:59 –––––––––––––––––––––––––––––– Para Contribuir PAYPAL : https://www.paypal.me/codetime Mercado Pago $100: https://mpago.la/1Zqo3G9 Mercado Pago $500: https://mpago.la/2MZ3oz3 Mercado Pago $1000: https://mpago.la/333qhPp –––––––––––––––––––––––––––––– Curso completo de desarrollo en Swift 4 desde cero https://www.udemy.com/curso-completo-de-swift-4-desde-cero/?couponCode=YOUTUBE_1 Curso de desarrollo de aplicaciones para iOS 11 desde cero https://www.udemy.com/desarrollo-de-aplicaciones-para-ios-11-desde-cero/?couponCode=YOUTUBE_1 –––––––––––––––––––––––––––––– Medios de contacto: Twitter / Telegram: @DavidGiordana Correo Electrónico: davidgiordana0@gmail.com Grupo en Telegram: https://t.me/joinchat/C-YEzBGu5Jh-mu8ejM2toA –––––––––––––––––––––––––––––– Canciones Utilizadas OP: Adventures by A Himitsu https://soundcloud.com/a-himitsu Creative Commons — Attribution 3.0 Unported— CC BY 3.0 Free Download / Stream: http://bit.ly/2Pj0MtT Music released by Argofox https://youtu.be/8BXNwnxaVQE Music promoted by Audio Library https://youtu.be/MkNeIUgNPQ8 ED: See You Tomorrow by GoSoundtrack http://www.gosoundtrack.com Creative Commons — Attribution 4.0 International — CC BY 4.0 Free Download / Stream: http://bit.ly/see-you-tomorrow Music promoted by Audio Library https://youtu.be/idlqqMHd0W4

- Disclaimers: 03:22 - Recapitulación: 05:45 - Funciones: - Funciones con demasiados argumentos: 07:21 - Argumentos de salida: 19:58 - Argumentos bandera: 26:11 - Funciones muertas: 32:41 - Generalidades: - Múltiples lenguajes en un solo archivo: 38:45 - Comportamiento obvio no implementado: 44:09 - Comportamiento incorrecto en condiciones borde: 53:26 - Cierre: 1:05:18 –––––––––––––––––––––––––––––– Para Contribuir PAYPAL : https://www.paypal.me/codetime Mercado Pago $100: https://mpago.la/1Zqo3G9 Mercado Pago $500: https://mpago.la/2MZ3oz3 Mercado Pago $1000: https://mpago.la/333qhPp –––––––––––––––––––––––––––––– Curso completo de desarrollo en Swift 4 desde cero https://www.udemy.com/curso-completo-de-swift-4-desde-cero/?couponCode=YOUTUBE_1 Curso de desarrollo de aplicaciones para iOS 11 desde cero https://www.udemy.com/desarrollo-de-aplicaciones-para-ios-11-desde-cero/?couponCode=YOUTUBE_1 –––––––––––––––––––––––––––––– Medios de contacto: Twitter / Telegram: @DavidGiordana Correo Electrónico: davidgiordana0@gmail.com Grupo en Telegram: https://t.me/joinchat/C-YEzBGu5Jh-mu8ejM2toA –––––––––––––––––––––––––––––– Canciones Utilizadas OP: Adventures by A Himitsu https://soundcloud.com/a-himitsu Creative Commons — Attribution 3.0 Unported— CC BY 3.0 Free Download / Stream: http://bit.ly/2Pj0MtT Music released by Argofox https://youtu.be/8BXNwnxaVQE Music promoted by Audio Library https://youtu.be/MkNeIUgNPQ8 ED: See You Tomorrow by GoSoundtrack http://www.gosoundtrack.com Creative Commons — Attribution 4.0 International — CC BY 4.0 Free Download / Stream: http://bit.ly/see-you-tomorrow Music promoted by Audio Library https://youtu.be/idlqqMHd0W4

In this episode we have legendary Robert Uncle Bob Martin come over to talk about Clean Code, professionalism, and courage. We cover:- the impact of Clean Code on businesses' ability to change software and make money- management pushback on applying Clean Code practices and how to handle it- how managers get to the truth and how developers get to the truth- professionalism, courage to take risk and saying NO despite potentially being fired- writing tests to reduce risks working with legacy (and not legacy) code- code ownership and pair programming- following the code rules you establish- a rapid questions round- ask listeners' questions- and much moreClean Code: Architecture & Design Masters Class for Software Developers . It starts September 6th: https://cleancodemastercourse2023.eventbrite.com/More Uncle Bob's events can be found here: http://thecleancoder.eventbrite.com/Clean Coders video courses: http://www.cleancoders.com/--- If you're looking for to simplifying software development with Clean Code reach out to: https://www.linkedin.com/company/clean-code-ventures/Prepping for a system design interview? Check out Alex's iOS System Design Interview video course: https://iosinterviewguide.com/system-design-interviewNeed to prepare for an iOS Engineer Interview?https://iosinterviewguide.comConnect with us:https://twitter.com/insideiosdevhttps://www.linkedin.com/in/alexvbush/https://www.linkedin.com/in/sandeep-aggarwal-629ab45a/https://twitter.com/alex_v_bushhttps://twitter.com/sandeepCool77Email us at hello@insideiosdev.com 

Clean Code - Why Formatting Mattersکد تمیز - فصل 6: فرمت‌بندی (قسمت 1)در این ویدیو، به بررسی فصل ششم کتاب "کد تمیز" می‌پردازیم و اهمیت فرمت‌بندی در نوشتن کد تمیز و قابل نگهداری را بررسی می‌کنیم. فرمت‌بندی کد موثر برای قابلیت خوانایی، درک و همکاری بین توسعه‌دهندگان بسیار حائز اهمیت است.ویدیو با بحث درباره اهمیت فرمت‌بندی در کد آغاز می‌شود. ما به مزایای کدی هماهنگ و خوب فرمت‌بندی شده می‌پردازیم، مانند بهبود خوانایی، کاهش بار شناختی و نگهداری آسان تر. همچنین، ما از Newspaper Metaphor برای بیان اهمیت فرمت‌بندی مناسب در سازماندهی کد استفاده می‌کنیم.سپس، به مطالعه فرمت‌بندی عمودی می‌پردازیم. فرمت‌بندی عمودی در برگرداندن کد اصولی، شامل بخش‌بندی، شکست خطوط و فاصله‌بندی عمودی است. ما روش‌ها و شیوه‌های مختلفی برای فرمت‌بندی عمودی معرفی و بهترین روش‌ها را بررسی می‌کنیم که می‌تواند کد ما را قابل خواندن‌تر و قابل انتقال‌تر کند. با اعمال این تکنیک‌ها، صرفه‌جویی در روشنایی و قابلیت نگهداری کد خواهیم داشت.در طول ویدیو، ما از مثال‌ها و قطعات کد عملی برای توضیح مفاهیم استفاده می‌کنیم. تا پایان این ویدیو، شما درک خوبی از اهمیت فرمت‌بندی در کد تمیز خواهید داشت و چگونگی استفاده از تکنیک‌های فرمت‌بندی عمودی را برای بهبود کدهای خود یاد خواهید گرفت.شروع (0:00)مقدمه و اهمیت فرمت‌بندی (1:51)Newspaper Metaphor (5:14)بررسی فرمت‌بندی عمودی (7:53)پایان (10:53)با ما در این ویدیوی آموزشی همراه شوید تا به دنیای فرمت‌بندی کد بپردازیم و یاد بگیریم چگونه کد خود را خوانا، قابل نگهداری و زیبا کنیم.---------------------------------------------------------------لینک کانال در سایر شبکه های اجتماعیYouTube:https://www.youtube.com/c/Ardiland1---------------------------------------------------------------Telegram:https://t.me/ardiland_tm---------------------------------------------------------------Instagram:https://www.instagram.com/ardiland_ig/---------------------------------------------------------------Twitter:https://twitter.com/Ardiland3---------------------------------------------------------------GitHub:https://github.com/ardalanebrahimi---------------------------------------------------------------LinkedIn:https://www.linkedin.com/in/ardalan-ebrahimi---------------------------------------------------------------

Clean Code - Bad Commentقسمت دوم از بررسی فصل 4 کتابClean Codeاین ویدئو دومین بخش از بررسی فصل چهارم، فصل کامنت هست.در این قسمت، در مورد دلایلی که باعث می‌شود در برنامه‌نویسی به کامنت ها حساس باشیم، صحبت می‌کنیم. در ویدئوی حاضر، به بررسی مشکلاتی که کامنت ها می‌توانند ایجاد کنند، مانند ایجاد ابهام در کد و حتی ایجاد باگ، می‌پردازیم. در طول ویدئو، به تفصیل به بررسی کامنت های ناکارآمد و مخرب می‌پردازیم.ویدئو شامل قطعات کد و نمونه عملی از هر یک از نمونه های ارائه شده است که به درک بهتر نکات بیان شده کمک می‌کند.شروع (0:00)Redundant Comments (1:05)Mandated Comments (2:16)Noise Comments (3:35)Use function and meaningful variable names instead of Comments (4:35)Closing Brace Comments (6:16)Commented-out Comments (8:12)Non local Information(11:12)Too much information (12:11)Inobviouse connection (12:50)پایان (14:15)درباره سری:برخی منابع و کتاب ها در دنیای برنامه نویسی به عنوان مرجع شناخته می شن و به برنامه نویسها در هر سطحی توصیه می شه که حتما این کتاب ها رو مطالعه کنن.تصمیم گرفتم که برخی از این کتاب ها رو به مرور در کانال اردیلند معرفی و بررسی کنم، به این صورت که هر کتاب رو فصل به فصل به صورت خلاصه تشریح کنم که هم با کلیات موضوع آشنا بشیم و هم نکات مهم یا کمی پیچیده تر رو به زبانی ساده برای مخاطب فارسی زبان تشریح کنم.اولین کتاب از این مجموعه، معروفترین و شاید مهترین کتاب مرجع برنامه نویسی هست یا کتاب معظم "کد تمیز" از رابرت مارتین یا باب مارتین یا همون "آنکل باب" معروفClean Code: A Handbook of Agile Software CraftsmanshipRobert C. Martin, aka Uncle Bobقطعه کد های مربوط به این ویدئو در گیت هاب در لینک زیر:https://github.com/ardalanebrahimi/Clean_Codeو در کانال تلگرام زیر موجود هست:https://t.me/ardiland_tm---------------------------------------------------------------لینک کانال در سایر شبکه های اجتماعیYouTube:https://www.youtube.com/c/Ardiland1---------------------------------------------------------------Telegram:https://t.me/ardiland_tm---------------------------------------------------------------Instagram:https://www.instagram.com/ardiland_ig/---------------------------------------------------------------Twitter:https://twitter.com/Ardiland3---------------------------------------------------------------GitHub:https://github.com/ardalanebrahimi---------------------------------------------------------------LinkedIn:https://www.linkedin.com/in/ardalan-ebrahimi---------------------------------------------------------------

Clean Code - Good Commentقسمت اول از بررسی فصل 4 کتابClean Codeاین ویدئو اولین بخش از بررسی فصل چهارم، فصل کامنت هست.تو این ویدئو میبینیم که چرا در برنامه نویسی باید به کامنت ها حساس باشیم، وقتی میگیم کامنت میتونه کد رو کثیف کنه و حتی تولید باگ کنه یعنی چی!در ادامه ویدئو چند مدل کامنت خوب رو معرفی می کنیم و در ویدئوی بعدی کامنت های بد و مخرب رو به تفصیل بررسی می کنیم.ویدئو شامل قطعه کد و نمونه عملی هر یک از نمونه های ارائه شده هست که دیدنشون به درک بهتر نکات مطرح شده کمک می کنه.شروع (0:00)کامنت دروغ میگه (1:41)Good Comments (7:07)پایان (13:11)درباره سری:برخی منابع و کتاب ها در دنیای برنامه نویسی به عنوان مرجع شناخته می شن و به برنامه نویسها در هر سطحی توصیه می شه که حتما این کتاب ها رو مطالعه کنن.تصمیم گرفتم که برخی از این کتاب ها رو به مرور در کانال اردیلند معرفی و بررسی کنم، به این صورت که هر کتاب رو فصل به فصل به صورت خلاصه تشریح کنم که هم با کلیات موضوع آشنا بشیم و هم نکات مهم یا کمی پیچیده تر رو به زبانی ساده برای مخاطب فارسی زبان تشریح کنم.اولین کتاب از این مجموعه، معروفترین و شاید مهترین کتاب مرجع برنامه نویسی هست یا کتاب معظم "کد تمیز" از رابرت مارتین یا باب مارتین یا همون "آنکل باب" معروفClean Code: A Handbook of Agile Software CraftsmanshipRobert C. Martin, aka Uncle Bobتو این فصل آنکل باب ازاهمیت داشتن توابع تمیز میگه و نکاتی رو برای ایجاد توابع تمیزتر و بهتر پیشنهاد و یادآوری میکنه، همراه با مثال ها و توضیحاتی که می تونید توی ویدئو ببینید.قطعه کد های مربوط به این ویدئو در گیت هاب در لینک زیر:https://github.com/ardalanebrahimi/Clean_Codeو در کانال تلگرام زیر موجود هست:https://t.me/ardiland_tm---------------------------------------------------------------لینک کانال در سایر شبکه های اجتماعیYouTube:https://www.youtube.com/c/Ardiland1---------------------------------------------------------------Telegram:https://t.me/ardiland_tm---------------------------------------------------------------Instagram:https://www.instagram.com/ardiland_ig/---------------------------------------------------------------Twitter:https://twitter.com/Ardiland3---------------------------------------------------------------GitHub:https://github.com/ardalanebrahimi---------------------------------------------------------------LinkedIn:https://www.linkedin.com/in/ardalan-ebrahimi---------------------------------------------------------------

Mais um episódio sobre TechGuide para vocês! Nesta conversa, vamos falar sobre os conceitos de Clean Code, por que existem e quais são essas boas práticas, muito pedidas em entrevistas de emprego. Vem ver quem acompanha a gente neste papo!

Clean code is one of those aspects of your programming career that's easy to put on the back burner (sometimes by management more than yourself). But it's important in the short term for writing more debuggable and readable code. And important in the long run for avoiding having your program take on the dreaded "legacy code" moniker. We're fortunate to have Bob Belderbos back on the show. He's been thinking and writing about clean code and Python a lot lately and we'll dive into a bunch of tips you can use right away to make your code cleaner. Links from the show Bob on Mastodon: @bbelderbos@fosstodon.org PyBites: pybit.es Tips for clean code in Python article: pybit.es Refactoring book: pybitesbooks.com Final type: docs.python.org Sentinels pattern: python-patterns.guide Black formater: pypi.org Guarding clauses: medium.com ChatGPT: chat.openai.com Git Precommit: pre-commit.com #100DaysOfCode in Python course: training.talkpython.fm #100DaysOfWeb in Python course: training.talkpython.fm Watch this episode on YouTube: youtube.com Episode transcripts: talkpython.fm --- Stay in touch with us --- Subscribe to us on YouTube: youtube.com Follow Talk Python on Mastodon: talkpython Follow Michael on Mastodon: mkennedy Sponsors Taipy Brilliant 2023 Talk Python Training