Podcasts about single responsibility principle

Play Episode Listen Later Oct 22, 2019 59:37

In this episode of Adventures in .NET the panel interviews Patrick Smacchia who is known for his static analyzer, NDepend. The panel discusses NDepend, Patrick explains a bit about what is and how it works along with his history in .NET. Patrick is here to explains SOLID, an acronym introduced by Robert C. Martin outlining principles for object-oriented programming. These principles teach programmers to use object-oriented programming correctly. The panel considers what can go wrong when object-oriented programming is misused. They also explain that the most important thing when it comes to SOLID is to try your best, it is impossible to be perfect in anything. Patrick explains that when your code is SOLID is will be easily testable and maintainable. The five principles are Single Responsibility, Open-Closed, Liskov Substitution, Interface Segregation, and Dependency Inversion. Of all the principles, Single Responsibility is unique. Patrick explains that this principle is all about organization and advises developers to be very careful when using this principle in your domain. The domain is where it is most important to have SOLID code and it needs to be 100% covered by testing. The panel shares that this is the principle that they try the hardest to follow. The definition given by Patrick for Single Responsibility is that a class should have a single responsibility or a class should have only one reason to change. Patrick warns the listeners that this is a very complex concept that is difficult to explain. The panel explains that Single Responsibility is a way to accomplish a separation of concern. The panel outlines the benefits of following this principle while Patrick shares some examples and walk the listeners implementing this principle. The next principle is Open-Closed. Patrick’s definition of this principle is modules should be open for extension but closed for modification. He and the panel dive deeper into what this means. He advises developers when designing a class to be very careful when choosing the point of variation and make sure you don’t change the code in your base class. Caleb shares the problems they experienced in one of his recent projects when this principle was not followed. Patrick explains why the solution is more often the interface rather than the base class. Moving on to the next principle, the Liskov substitution. Patrick explains how this principle using the example of the ibird. The Liskov substitution principle is that objects in a program should be replaceable so that you can’t tell the difference. In the ibird example, you can not replace the ibird with any bird because if the ibird can fly but the replacement bird is an ostrich it cannot perform the necessary functions. Patrick explains how ilists are in opposition to the Liskov principle. Next is the Interface Segregation Principle. Patrick explains how this relates to the Single Responsibility Principle. He also discusses how the Liskov Substitution and the Interface Segregation are two sides of the same coin when it comes to designing interfaces. The Interface Segregation explains that many smaller client-specific interfaces are better that one large interface with everything on it. The final principle is Dependency Inversion. Patrick explains that this principle does not help you design your interface, it helps you organize dependencies into your code structure. This principle advises developers to depend on abstractions. He explains how this principle relates to dependency injection. The panel considers the damage dependencies can cause in a codebase if improperly used. Patrick explains when a developer will want to use abstractions and when to use classes. He explains that these 5 principles will become natural and feel like common sense as developers gain experience. Switching gears, the panel moves on to discuss a blogpost Patrick wrote explaining 4 predictions he had for the future of .NET. He wrote the article because of the announcement that .NET core will become .NET 5. The future of .NET has a great impact on NDepend and Patrick wanted to give some perspective to the changes and how they might affect his company. His first prediction is that .NET standards won’t evolve much. Patrick explains that the purpose of .NET Standards was to support all the .NET flavors and with only .NET to support that job will become much simpler. He also speculates on the reasons for Microsoft wanting only one .NET. Some of the reasons he lists are that Microsoft does not have an endless workforce and .NET core is open source and multiplatform. Patrick’s second prediction greatly impacts NDepend. His prediction is that Visual Studios will run on .NET 5, explaining why he is so sure that they will switch Visual Studios over to .NET 5. Patrick believes that it may take a while for the switch to happen. The panel considers the future of Windows. The third prediction Patrick makes is that .NET will propose a cross-platform UI framework. Microsoft did a poll asking developers about the need for a cross-platform UI framework. The panel speculates how this framework will happen. Patrick wonders at the possibility of WPF. The panel brings up the final prediction, that Blazor has a bright future, and wonder if Blazor could become that cross-platform UI framework. Panelists Shawn Clabough Caleb Wells Guest Patrick Smacchia Sponsors My Ruby Story React Native Radio Adventures in Angular CacheFly Links www.ndepend.com SOLID 4 Predictions for the Future of .NET Satya Nadella reveals why Windows may not be the future of Microsoft’s business .NET 003: Blazor with Daniel Roth https://www.facebook.com/Adventures-in-NET-373059030062837/ https://twitter.com/dotNET_Podcast Picks Caleb Wells: https://www.packtpub.com/free-learning Shawn Clabough: https://conemu.github.io/

moving future predictions microsoft adventures windows solid switching ui panelists satya nadella angular cachefly wpf blazor daniel roth robert c martin react native radio liskov single responsibility principle dependency inversion shawn clabough dotnet podcast

Interface Segregation

Play Episode Listen Later Sep 2, 2019 5:57

Hi and welcome back to Weekly Dev Tips. I’m your host Steve Smith, aka Ardalis. This is episode 55, on the Interface Segregation principle. Interface Segregation Principle This week's tip is brought to you by devBetter.com. Sponsor - devBetter Group Career Coaching for Developers You can find help and advice all over today, from twitter to Stack Overflow to various Slack communities. These are great, but if you need more, if you need someone you can count on when you reach out for advice on code or your career, check out devBetter.com. Read the testimonials. Join risk free and see if it's for you. Not only will you learn from me, but if you stay for a while you'll grow and begin to be a mentor for others, gaining valuable confidence and experience. I've watched it happen. Show Notes / Transcript Returning back to the next SOLID principle, this week we're on the I as in Interface. Yes, it's the Interface Segregation Principle! Or ISP for short. Let's start by defining what this principle says. ISP states that no client should be forced to depend on methods it does not use. That's it. You can think of ISP as basically suggesting that you should prefer small, cohesive interfaces to large interfaces. In episode 49, which hopefully you already heard because you're listening to these in sequential order, we talked about the Single Responsibility Principle. These two principles are related! If you have classes that have only one responsibility, they're likely to expose a small, cohesive interface. That might be worth diving into a bit more. I'm guessing that when some developers, especially C# or Java developers, hear about ISP, they immediately map the word 'interface' to the interface type and keyword in these languages. That's not wrong, it's just not fully right, either. The public methods and properties a class exposes are its interface, even if it doesn't implement any interface defined separately. And ISP applies to implicit class interfaces just as much as it does to explicit interface definitions declared with the interface type. If you keep this in mind, it may make it easier to see how SRP and ISP relate, since SRP doesn't make any mention of interface types, only classes. The previous principle we discussed, Liskov Substitution, also relates to ISP. If you have a small, cohesive interface on a class, then when you decide to inherit from it you only have a few methods to worry about. If you have a massive number of methods, and your subtype is only concerned with a subset of them, it's much more likely that you won't fully implement all of the class's methods, potentially leaving some methods to throw NotImplementedException. Thus, it's easier to follow LSP if you first follow ISP. What's the point of having a smaller interface instead of a larger one, though? What's the down side to having fewer, larger classes with many methods on them? Certainly there's an argument to be made, and many have, that it makes it easier to find methods when you don't have so many different classes to search through to find them. The goal of ISP is to reduce dependency between types and especially between components in a system. The more types that depend on a particular type, the more difficult that type is to change. The more inertia it has in the system. If you have a class in your application that's used by 100 other classes, how likely are you to make major changes to its design, compared to one that you just wrote that has literally no other classes using it yet? Of course it's easier and WAY less risky to change classes that have few references to them. Let's say you want to change something fundamental about how that class that's used by 100 other classes works. One way you could do that would be to create a new instance of that class's interface or abstract base class, but then you'd have to implement all of its methods. Odds are, there are a bunch of them. That's not going to be easy - so instead you might just add some more conditional logic to some of the methods. Maybe add a few more method parameters to some methods. Maybe add a couple of new method overloads. And guess what? The problem just got bigger. The class just got bigger. The inertia just grew. By having a small interface and being focused on a small set of functionality, ISP-following classes are easier to change an easier to replace. By being small, they're easier to subtype or implement, making it easier to build systems that are modular. You find a class that has two methods and you want to change how it works in some situations? Just write a new class, implement the two methods, and swap it in where appropriate. Prefer writing new code to change legacy systems rather than modifying existing code. By following ISP, it's easier to replace classes with different variants that implement the same interface, which results in more loosely coupled and modular designs. These designs are easier to maintain and easier to test. You can learn more about ISP and the rest of the SOLID principles from my courses on Pluralsight, linked from this episode's show notes on weeklydevtips.com/episodes/55. Show Resources and Links devBetter SOLID Principles for C# Developers SOLID Principles of Object Oriented Design -and the DRY Principle Refactoring for C# Developers That’s it for this week. If you want to hear more from me, go to ardalis.com/tips to sign up for a free tip in your inbox every Wednesday. I'm also streaming programming topics on twitch.tv/ardalis most Fridays at noon Eastern Time. Thank you for subscribing to Weekly Dev Tips, and I'll see you next week with another great developer tip.

tips odds solid programming slack java prefer dev segregation interface steve smith software development isp stack overflow pluralsight oop lsp srp clean code single responsibility principle

Single Responsibility Principle

Play Episode Listen Later May 20, 2019 5:46

Hi and welcome back to Weekly Dev Tips. I’m your host Steve Smith, aka Ardalis. This is episode 49 on the Single Responsibility Principle. Single Responsibility This week's tip is brought to you by devBetter.com. Sponsor - devBetter Group Career Coaching for Developers Are you a software developer looking to advance in your career more quickly? Would you find a mentor and a group of like-minded professionals valuable? If so, check out devBetter.com and read the testimonials at the bottom of the page. Sign up for a risk free membership if you're interested in growing your network and skills with us. Show Notes / Transcript The Single Responsibility Principle, or SRP, is the S in the SOLID principles macronym. The short version of it is that a class should have only one reason to change. Specifically, the reason referred to here is tied to the application's requirements. Each class should only be required to change in response to a single change in the application's requirements. These requirements typically correspond to real world things. For example, let's say the application needs to display a report for quarterly sales performance. The system's requirements might be that the report be rendered in a browser, that it include all sales for a given quarter grouped by individual sales representative. Either of these requirements might change in the future. Perhaps the reports need to be emailed as PDFs. Perhaps they need to be calculated monthly instead of quarterly or rolled up by sales region. Ideally, the format of the report and the details of how it is calculated should be separate responsibilities of separate classes. Why is SRP important? Back in episode 15, Maintain Legacy Code with New Code, I explain one reason. Every time you change a class, you risk breaking classes that work with it. When a class has multiple responsibilities, it will likely need to change more often. Also, it's likely these responsibilities will be tightly coupled together by the class, making it harder to change them independently and further increasing the inherent risk of changing them. Let's say you have to fix a bug in an application. Would you rather have to work in a single class that literally only does the thing that has the bug in it, or would you prefer to work in a 2000 line long class that does 10 different things, all of which are intermixed in the class's 50 methods and properties? I know which one I prefer. Too often, developers new to SOLID will hear about SRP and misunderstand a bit what a responsibility really is. They might have a class they've carved out from the rest of the application. Something like CustomerManager. They'll happily explain how CustomerManager is only responsible for Customers in the application, and thus is following SRP. But upon reviewing the code, it's clear that CustomerManager is responsible for Customer validation, Customer persistence, and Customer formatting for various user interfaces. It's responsible for notifying Customers when they place orders and oh yeah, it also is responsible for Customers placing orders, as well as managing their orders and their payment providers and their account history. But don't worry - CustomerManager only has one responsibility: Customers! Although I said responsibilities typically map to business requirements, they don't typically map to entities like customers or orders or policies. This is because these entities will often have a lot of rich behavior that can be isolated into separate responsibilities, often with cross-cutting concerns within the application. For instance, how a customer is validated will likely be very similar to how an order is validated. The same goes for persistence and UI formatting and a host of other activities. Each of these is a responsibility, and should be isolated in its own class. Now, it might seem like breaking up big classes into small ones is going to result in a lot more code, but often just the opposite occurs. As you pull cross-cutting concerns like validation, persistence, logging, notifications, formatting, etc. into their own classes, you'll often find ways to standardize the codebase and reuse these classes. A common way to achieve this reuse is through the strategy pattern, which I discuss in episode episode 19. The Strategy pattern lets you move responsibilities out of a class by delegating to other classes, which are often defined as fields or properties on the original class. These fields or properties have their instances set by having them passed in through the constructor, in what's commonly called dependency injection. Dependency injection and the strategy design pattern go hand-in-hand, and are my favorite way to refactor to achieve SRP in classes that I find have too many responsibilities. If you'd like to learn more about SRP and SOLID, check out my newly revised course, SOLID Principles for C# Developers, on Pluralsight. It's a complete update of my original SOLID Principles of Object Oriented Design course that has been in the top 100 for Pluralsight since it was published in 2010. The new one is shorter and streamlined, though it doesn't cover some topics the original course has. The new course also uses Visual Studio 2019 and has all of its course samples on GitHub. Check both of them out and let me know what you think. Show Resources and Links devBetter SOLID Principles for C# Developers SOLID Principles of Object Oriented Design -and the DRY Principle Refactoring Fundamentals That’s it for this week. If you want to hear more from me, go to ardalis.com/tips to sign up for a free tip in your inbox every Wednesday. I'm also streaming programming topics on twitch.tv/ardalis most Fridays at noon Eastern Time. Thank you for subscribing to Weekly Dev Tips, and I'll see you next week with another great developer tip.

strategy testing customers solid programming coding ui github dependency pdfs steve smith software development tdd visual studio pluralsight continuous integration design patterns srp clean code dependency injection solid principles single responsibility principle dependency inversion

Introducing SOLID Principles

Thoughts on Functional Programming Podcast by Eric Normand

Play Episode Listen Later May 6, 2019 7:26

Hi and welcome back to Weekly Dev Tips. I’m your host Steve Smith, aka Ardalis. This is episode 47, in which we'll introduce the SOLID principles. I'll spend a little time reviewing these principles in the upcoming episodes. What are the SOLID principles of object-oriented design? Sponsor - devBetter Group Career Coaching for Developers Are you a software developer looking to advance in your career more quickly? Would you find a mentor and a group of like-minded professionals valuable? If so, check out devBetter.com and read the testimonials at the bottom of the page. Sign up for a risk free membership if you're interested in growing your network and skills with us. Show Notes / Transcript Depending on how long you've been programming, you may have heard of the SOLID principles. These are a set of 5 principles that have been around for several decades, and about 15 years ago someone - I think it was Michael Feathers - had the idea to arrange them in such a way that they formed the macronym SOLID. Prior to that, I think the first time they were all published together was in Robert C. Martin's 2003 book, Agile Software Development: Principles, Patterns, and Practices in which their sequence spelled SOLDI - so close! This same sequence was used in the 2006 book Agile Principles, Patterns, and Practices in C#. So what are the SOLID principles? As I mentioned, SOLID is a macronym, meaning it is an acronym formed by other acronyms. In this case, these are SRP, OCP, LSP, ISP, and DIP. All those Ps at the end of each acronym stand for principle, of course. Listing each principle, we have: Single Responsibility Open/Closed Liskov Substitution Interface Segregation Dependency Inversion You may already be familiar with these principles. If you're a developer who's using a strongly typed language like C# or Java, you should be extremely familiar with them. If you're not, I recommend digging into them more deeply. Applying them can make a massive difference in the quality of code you write. How do I define quality? Well, that's probably a topic I could devote an episode to, but the short version is that quality code is code that is easy to understand and easy to change to suit new requirements. It's easily and quickly tested by automated tests, which reduces the need for expensive manual testing. And it's loosely coupled to infrastructure concerns like databases or files. How do these principles help you to write quality code? They provide guidance. You need to write code that solves a problem, first and foremost. But once you have code that does that, before you call it done and check it in, you should evaluate its design and see if it makes sense to spend a few moments cleaning anything up. Back in Episode 6 - you are listening to these in sequential, not reverse, order, right? - I talked about Kent Beck's approach of Make It Work, Make It Right, Make It Fast. SOLID principles should generally be applied during the Make It Right step. Don't apply them up front, but as I discussed in Episode 10, follow Pain Driven Development. If you try to apply every principle to every part of your codebase from the start, you'll end up with extremely abstract code that could do anything but actually does nothing. Don't do that. Instead, build the code you need to solve the problem at hand, and then evaluate whether that code has any major code smells like I discussed in episode 30. One huge code smell is code that is hard to unit test, meaning it's hard to write an automated test that can just test your code, without any external infrastructure or dependencies like databases, files, or web servers. Code that is easy to unit test is generally easy to change, and code that has tests is also easier to refactor because when you're done you'll have some degree of confidence that you haven't broken anything. In upcoming episodes, I'll drill into each principle a bit more. I've published two courses on SOLID at Pluralsight where you can obviously learn a lot more and see real code as opposed to just hearing me through a podcast. The first one was published in 2010 and so the tools and look were a bit dated. The more recent one is slimmed down and uses the latest version of Visual Studio and .NET Core. There are links to both courses in the show notes - the original one also covers the Don't Repeat Yourself principle. Let me wrap this episode up with a very brief overview of each principle. The Single Responsibility Principle is generally applied to classes and suggests that classes should have only one responsibility, which can also be thought of as one reason to change. Responsibilities include things like business logic, ui logic, data access, and more. Following this principle, you'll tend to have smaller, more focused classes. The Open/Closed Principle suggests that you should be able to change the behavior of your system without changing its source code. This generally relies on some kind of parameter or plug-in capability to provide new behavior to an existing class or service. The Liskov Substitution Principle cautions against creating inheritance hierarchies in which child types are not 100% substitutable for their base types. When violated, this can result in messy code and bugs. The Interface Segregation Principle suggests that classes that use interfaces should use all or most of the interface's exposed members. This then leads to interfaces that are small, focused, and cohesive, much like SRP. Finally, the Dependency Inversion Principle recommends that low-level concerns depend on high level concerns, not the other way around. This means for example that business layer code shouldn't directly depend on data access code, but rather an abstraction should exist that the business code works with and that the data access code implements. At runtime, the data access code will be provided as an implementation of the interface the business code is written to work with, providing loose coupling and more testable code. Show Resources and Links devBetter SOLID Principles for C# on Pluralsight Refactoring Fundamentals on Pluralsight SOLID Principles of Object Oriented Design on Pluralsight (published in 2010) Agile Software Development: Principles, Patterns, and Practices on Amazon Agile Principles, Patterns, and Practices in C# on Amazon See Visualizations and Subscribe to WeeklyDevTips in YouTube Clean Code on Amazon That’s it for this week. If you want to hear more from me, go to ardalis.com/tips to sign up for a free tip in your inbox every Wednesday. I'm also streaming programming topics on twitch.tv/ardalis most Fridays at noon Eastern Time. Thank you for subscribing to Weekly Dev Tips, and I'll see you next week with another great developer tip.

testing code responsibility ps practices patterns solid programming coding java listing dip steve smith software development isp make it work soldi tdd visual studio make it right pluralsight ocp lsp srp net core clean code kent beck robert c martin michael feathers solid principles uncle bob martin single responsibility principle

Single Responsibility Principle for Functional Programming

Play Episode Listen Later Oct 11, 2018 10:59

How do functional programmers use the Single Responsibility Principle?

functional programming single responsibility principle

Layering Patterns on Repositories

Anwendungsentwickler-Podcast

Play Episode Listen Later Aug 27, 2018 7:28

Layering Patterns on Repositories This week we're sticking to the patterns and repositories theme. I started down the design patterns path with Episode 17 so start at least from there if you want to listen to the sequence more-or-less in order. In this episode, we'll look at some combinations with other patterns that make using the Repository pattern even more attractive. Sponsor - DevIQ Thanks to DevIQ for sponsoring this episode! Check out their list of available courses and how-to videos. Show Notes / Transcript Last week I mentioned how the Repository pattern works well with the Strategy pattern, so that you can use dependency injection with it. This is the first of many ways in which you can combine Repository with other patterns, and is probably the most powerful of them all (though probably taken for granted by many). I described the strategy pattern in episode 19. Let's look at two other patterns now that we can combine with Repository. First, let's talk about a common pain point with repositories: custom queries. I talked about the need to encapsulate query logic so it doesn't leak out of your repository in episode 18. However, I saved a powerful technique for doing so until this tip. (Sorry, there's only so much I can put into each of these and keep them short.) If you follow my earlier advice and you don't leak query logic outside of your repositories, it's likely your repository implementations have a bunch of custom query methods. Maybe you have standard GetById and List methods, but then you also have ListByState, ListByModel, ListByOwner, etc. Maybe you have methods that correlate directly to business use cases or even UI concerns, like ListPremiumCustomers or ListForSearchScreen. The point is, you may find yourself with the code smell of too many one-off custom query methods on your repositories. This is pretty common, and the worse it gets the more cumbsersome it becomes to work with the repositories. The solution to this problem is to introduce another pattern. The Specification pattern is designed to encapsulate a query within an object. I mentioned it briefly in episode 24. It's especially useful when you're using an ORM tool like EF or EF Core because not only can you encapsulate filter expressions, but you can also specify which properties to eager load. Thus, you can create a specification for a shopping basket type that might be called BasketWithItemsByCustomerId or something similar. A typical specification I use will include the filter expression (to be used with a Where LINQ expression) and will let me specify which properties and subproperties I want the query to return with it. What are the benefits of using this pattern? First, you eliminate duplication of query logic if you were previously letting client code create queries on the fly. Second, you establish a library of known queries that your development team can review, reuse, and discuss. These should be organized so they're extremely discoverable so there's minimal need to try and reinvent the wheel when someone needs a particular query that already exists. They also help clean up your repositories, eliminating most of the scenarios where you would need non-generic repository methods, and thus dramatically reducing how many repository implementations you need to write and maintain. Your repository code will better follow the Single Responsibility Principle and the Open/Closed Principle, and you won't need a bunch of custom IWhateverRepository interfaces. Finally, you can easily unit test your specifications' filter logic to ensure it's correct and provide examples for the team. Another useful pattern you can use with repository is the proxy or decorator pattern to add caching. I call this the CachedRepository pattern and I've written a number of articles about it. I mention both patterns because they're functionally the same, but differ based on intent. A proxy controls access to something. A decorator adds behavior to something. A CachedRepository controls access to the real, underlying repository, exposing it only when the result isn't in the cache. In this way, it's a proxy. But it also is responsible for adding caching behavior to any repository. In this way, it's a decorator. Either way, it's an extremely useful pattern. Most applications make a lot of queries to their database for results that don't change frequently. A lot of applications use a database to define some or all of their navigation, or the contents of common dropdownlists on forms. These and other common results are great candidates for caching, but often this behavior isn't added because of the work and complexity involved. Adding caching to a method in a data access repository isn't ideal, since it couples two unrelated concerns and breaks the single responsibility principle. It's also not very reusable. A better approach is to create a generic CachedRepository that can be used for any type that would benefit from caching. Determining whether or not to use this caching functionality can be controlled centrally for the application wherever its services are configured. Circling back around to the specification pattern, you can combine it with the CachedRepository to help with key generation. Every cache entry needs to have a unique key, and you need to take care when constructing keys that you take into account any variables or parameters that were used for a particular query. Your specification objects know exactly which parameters they require, and can easily expose a cache key property that can be used by your CachedRepository. You can also add a property to toggle whether certain specifications should be cached at all, if that's helpful. If you'd like to see what this looks like in a simple sample application, check out the eShopOnWeb sample on GitHub. I have a link in the show notes. There's also a free 110-page eBook that goes along with the sample that I encourage you to check out. I developed both the book and the sample for Microsoft as a free resource and they're both up-to-date with .NET Core 2.1 as of July 2018. Do you think your team or application could be improved by better use of design patterns? I offer remote and onsite workshops guaranteed to improve your coding skills and application code quality. Contact me at ardalis.com and let's see how I can help. Show Resources and Links Repository Pattern SOLID Principles Specification Pattern Building a CachedRepository in ASP.NET Core Introducing the CachedRepository Pattern Building a CachedRepository via Strategy Pattern

strategy microsoft ebooks patterns ui github ef circling asp layering specifications orm repository net core repositories ef core single responsibility principle

Single Responsibility Principle (SRP) – Wissenshäppchen #3

Play Episode Listen Later Jun 3, 2018 26:46

Mein drittes Wissenshäppchen hat das Single Responsibility Principle zum Thema. Inhalt Das SRP ist das erste der sogenannten SOLID-Prinzipien. Robert „Uncle Bob“ Martin definiert es so: There should never be more than one reason for a class to change. Jede Klasse sollte genau einen einzigen Grund haben, um geändert zu werden. Man kann das Prinzip... Der Beitrag Single Responsibility Principle (SRP) – Wissenshäppchen #3 erschien zuerst auf IT-Berufe-Podcast.

man thema grund prinzip der beitrag single responsibility principle wissensh

20. Simple Made Easy

Fatal Error

Play Episode Listen Later Mar 6, 2017 31:07

Simple Made Easy by Rich Hickey “Rich Hickey emphasizes simplicity's virtues over easiness', showing that while many choose easiness they may end up with complexity, and the better way is to choose easiness along the simplicity path.” Talk Transcript, with slides Fatal Error episode 7: The Single Responsibility Principle Fatal Error episode 15: Not Invented Here Some examples we mention: Object-Relational Mapping vs Key-value Database CocoaPods vs. Carthage Slides mentioned in this post: Development Speed Simplicity Made Easy

object databases slides carthage fatal error cocoapods rich hickey not invented here single responsibility principle simple made easy

7. The Single Responsibility Principle

Fatal Error

Play Episode Listen Later Oct 24, 2016 36:24

A responsibility is an axis of change — a potential motivation for change. SRP is the S in SOLID Book chapter about SRP from Uncle Bob via Uncle Bob's Principles of Object-Oriented Design Single Responsibility Principle: A Recipe for Great Code SRP in Ruby Off-topic: Falsehoods Programmers Believe About Names A Controller By Any Other Name (Soroush) Episode 2: View Models

single principles solid uncle bob srp soroush single responsibility principle

QED 16: Elements

Q.E.D. Code

Play Episode Listen Later Aug 14, 2016 17:42

Euclid's Elements takes a disciplined, formal approach to proving assertions based only on simple axiomatic statements. While most of these axioms are elegant, one of them is more complex and wordy. It seems as if it should be provable from the others. Several mathematicians have tried, but eventually they found a surprising result. Beware when proving your own assertions that you don't make the mistake of assuming something that seems obvious. Category theory isn't as complex as you might be lead to believe. A category is nothing more than a contract that sets rules on how a type is to behave. Functors, despite having a weird name, are just types that can map functions into a different space. The List type is an example of a functor, because it can transform a function on its elements into a function on lists. And Applicatives are just wrapper types. They are especially useful for building pipelines. CQRS, Command Query Responsibility Segregation, is a pattern that applies the Single Responsibility Principle to components such that they either change the system (commands), or observe it (queries). Segregation alone gives us the ability to prove some very useful things about a system: safety, determinism, and consistency for example. But it does not prescribe asynchrony or eventual consistency. Those are architectural decisions left to you.

elements cqrs single responsibility principle euclid's elements

237 RR Rails + JavaScript + Functional Programming with Brad Urani

Play Episode Listen Later Dec 9, 2015 57:02

Check out JS Remote Conf and All Remote Confs! 02:32 - Brad Urani Introduction Twitter GitHub Blog Procore 04:01 - Immutable/Persistent Data Structures; Advantages Changing the Unchangeable: The Hows and Whys of Immutable Data Structures @ RubyConf 2015 hamster 07:30 - Tools for Debugging 08:23 - Why do Rubyists care about things like Elm? 09:39 - Persistent Data Structure Use Cases; Functional Programming 12:07 - Testability 13:51 - Where does “functional play a role in a typical CRUD app? Active Record, The Single Responsibility Principle (SRP) Callbacks Object-oriented Programming (OOP) “Nouns are objects; verbs are methods” - Corey Haines 22:49 - Coworker Receptiveness of Ruby + JavaScript Style of Programming Codebase Inconsistency? “Merit” 26:41 - Service-oriented Architecture (SOA) vs Monolithic Applications Remote Procedure Calls (RPC) Representational State Transfer (REST) 30:21 - Monoliths as a Necessary Stage in the Development of a Mature Application Elixir The Phoenix Framework ecto 33:23 - The Repository Pattern; Terminology & Naming Patterns of Enterprise Application Architecture by Martin Fowler 37:40 - Structured Query Language (SQL) Avdi Grimm: The Soul of Software @ RubyConf Portugal '15 The Sapir Whorf Hypothesis' Picks Dan Carlin's Hardcore History (Coraline) Stuff You Missed in History Class (Coraline) Buffer (Avdi) New Belgium Brewing Accumulation White IPA (Avdi) Saramonic SmartMixer Professional Recording Stereo Microphone Rig (Chuck) LaunchCode (Brad) Turing's Cathedral: The Origins of the Digital Universe by George Dyson (Coraline) VAT19 (Brad)

service development tools single blog remote architecture patterns programming advantages naming object github linguistics merit javascript rails buffer terminology elixir sql turing whys elm creativeasin nouns soa debugging monoliths dan carlin oop hardcore history callbacks 3d4 monolithic crud rpc history class srp procore functional programming martin fowler launchcode representational stuff you missed corey haines activerecord avdi george dyson digital universe sapir whorf hypothesis testability rubyists single responsibility principle phoenix framework vat19 js remote conf all remote confs

237 RR Rails + JavaScript + Functional Programming with Brad Urani

Play Episode Listen Later Dec 9, 2015 57:02

Check out JS Remote Conf and All Remote Confs! 02:32 - Brad Urani Introduction Twitter GitHub Blog Procore 04:01 - Immutable/Persistent Data Structures; Advantages Changing the Unchangeable: The Hows and Whys of Immutable Data Structures @ RubyConf 2015 hamster 07:30 - Tools for Debugging 08:23 - Why do Rubyists care about things like Elm? 09:39 - Persistent Data Structure Use Cases; Functional Programming 12:07 - Testability 13:51 - Where does “functional play a role in a typical CRUD app? Active Record, The Single Responsibility Principle (SRP) Callbacks Object-oriented Programming (OOP) “Nouns are objects; verbs are methods” - Corey Haines 22:49 - Coworker Receptiveness of Ruby + JavaScript Style of Programming Codebase Inconsistency? “Merit” 26:41 - Service-oriented Architecture (SOA) vs Monolithic Applications Remote Procedure Calls (RPC) Representational State Transfer (REST) 30:21 - Monoliths as a Necessary Stage in the Development of a Mature Application Elixir The Phoenix Framework ecto 33:23 - The Repository Pattern; Terminology & Naming Patterns of Enterprise Application Architecture by Martin Fowler 37:40 - Structured Query Language (SQL) Avdi Grimm: The Soul of Software @ RubyConf Portugal '15 The Sapir Whorf Hypothesis' Picks Dan Carlin's Hardcore History (Coraline) Stuff You Missed in History Class (Coraline) Buffer (Avdi) New Belgium Brewing Accumulation White IPA (Avdi) Saramonic SmartMixer Professional Recording Stereo Microphone Rig (Chuck) LaunchCode (Brad) Turing's Cathedral: The Origins of the Digital Universe by George Dyson (Coraline) VAT19 (Brad)

service development tools single blog remote architecture patterns programming advantages naming object github linguistics merit javascript rails buffer terminology elixir sql turing whys elm creativeasin nouns soa debugging monoliths dan carlin oop hardcore history callbacks 3d4 monolithic crud rpc history class srp procore functional programming martin fowler launchcode representational stuff you missed corey haines activerecord avdi george dyson digital universe sapir whorf hypothesis testability rubyists single responsibility principle phoenix framework vat19 js remote conf all remote confs

237 RR Rails + JavaScript + Functional Programming with Brad Urani

Play Episode Listen Later Dec 9, 2015 57:02

Check out JS Remote Conf and All Remote Confs! 02:32 - Brad Urani Introduction Twitter GitHub Blog Procore 04:01 - Immutable/Persistent Data Structures; Advantages Changing the Unchangeable: The Hows and Whys of Immutable Data Structures @ RubyConf 2015 hamster 07:30 - Tools for Debugging 08:23 - Why do Rubyists care about things like Elm? 09:39 - Persistent Data Structure Use Cases; Functional Programming 12:07 - Testability 13:51 - Where does “functional play a role in a typical CRUD app? Active Record, The Single Responsibility Principle (SRP) Callbacks Object-oriented Programming (OOP) “Nouns are objects; verbs are methods” - Corey Haines 22:49 - Coworker Receptiveness of Ruby + JavaScript Style of Programming Codebase Inconsistency? “Merit” 26:41 - Service-oriented Architecture (SOA) vs Monolithic Applications Remote Procedure Calls (RPC) Representational State Transfer (REST) 30:21 - Monoliths as a Necessary Stage in the Development of a Mature Application Elixir The Phoenix Framework ecto 33:23 - The Repository Pattern; Terminology & Naming Patterns of Enterprise Application Architecture by Martin Fowler 37:40 - Structured Query Language (SQL) Avdi Grimm: The Soul of Software @ RubyConf Portugal '15 The Sapir Whorf Hypothesis' Picks Dan Carlin's Hardcore History (Coraline) Stuff You Missed in History Class (Coraline) Buffer (Avdi) New Belgium Brewing Accumulation White IPA (Avdi) Saramonic SmartMixer Professional Recording Stereo Microphone Rig (Chuck) LaunchCode (Brad) Turing's Cathedral: The Origins of the Digital Universe by George Dyson (Coraline) VAT19 (Brad)

service development tools single blog remote architecture patterns programming advantages naming object github linguistics merit javascript rails buffer terminology elixir sql turing whys elm creativeasin nouns soa debugging monoliths dan carlin oop hardcore history callbacks 3d4 monolithic crud rpc history class srp procore functional programming martin fowler launchcode representational stuff you missed corey haines activerecord avdi george dyson digital universe sapir whorf hypothesis testability rubyists single responsibility principle phoenix framework vat19 js remote conf all remote confs

Single Responsibility Principle: A Class Should Have One, and Only One Reason to Change

Developer Tea

Play Episode Listen Later Aug 3, 2015 9:51

In today's episode I review why focus is so important to coding. Today's episode is presented by DigitalOcean. Go to https://digitalocean.com to get started, and use the promo code DEVELOPER TEA at the checkout after you create your account to get a $10 credit!

class one reason digital ocean developer tea single responsibility principle

211 RR DCI with Jim Gay

Play Episode Listen Later Jun 10, 2015 55:50

02:48 - Jim Gay Introduction Twitter GitHub Blog Ruby DSL Handbook 03:43 - Object Design Clean Ruby SOLID Principles 04:39 - DCI (Data, Context, Interaction) Main Resource for DCI (FullOO) 07:20 - What Painpoint DCI Aims to Solve The Gang of Four Book object-composition Mailing List (Google Group) 09:31 - Designing From DCI From the Start (Process) Levels of Use Cases Writing Effective Use Cases by Alistair Cockburn 11:42 - Object Composition Single Responsibility Principle 13:56 - Definitions: Forwarding, Delegation, Consultation, and Inheritance Class-Based Inheritance vs Prototype-Based Inheritance JavaScript Influence 18:37 - DCI and Service Objects Context 24:36 - Roles and Object Factoring Authentication 28:49 - One Context in a Single File surrounded 30:17 - Coupling and Cohesion 31:37 - Typeclasses 33:09 - DCI Criticism casting 36:51 - The Current State of DCI (Skepticism & Criticism?) Domain-Driven Design 38:56 - Preventing Reuse 41:18 - When should you not use DCI? 43:45 - Transition: Using/Undoing DCI (Experimentation) 45:04 - Resources fulloo.info Marvin object-composition Mailing List (Google Group) Clean Ruby More DCI Blog Posts by Jim Delegation Is Everything And Inheritance Does Not Exist Chubby Models Are Still Fat With Concerns. DCI Focuses On How Things Work Together The Gang Of Four Is Wrong And You Don't Understand Delegation Triggering The DCI Context OOP, DCI And Ruby - What Your System Is Vs. What Your System Does 4 Simple Steps - Extending Ruby Objects - The Tip Of The Iceberg With DCI Picks Richard Hamming: You and Your Research (Jessica) Martin Fowler: Yagni (Coraline) Ruby Monday (Saron) JunkFill (Saron) Wappalyzer (Saron) WhatFont (Saron) Julian Feliciano: What Is Source Control? (Saron) Bodum Santos Stovetop Glass Vacuum 34-Ounce Coffee Maker (Avdi) The Master and His Emissary: The Divided Brain and the Making of the Western World by Iain McGilchrist (Jim) request_store_rails (Jim) littleBits (Jim)

master data single blog gang levels context solve roles criticism solid inheritance current state delegation object github interaction domain consultation use cases western world authentication creativeasin cohesion coupling oop dci design patterns iain mcgilchrist domain driven design saron littlebits avdi alistair cockburn yagni solid principles single responsibility principle your research jim gay

211 RR DCI with Jim Gay

Play Episode Listen Later Jun 10, 2015 55:50

02:48 - Jim Gay Introduction Twitter GitHub Blog Ruby DSL Handbook 03:43 - Object Design Clean Ruby SOLID Principles 04:39 - DCI (Data, Context, Interaction) Main Resource for DCI (FullOO) 07:20 - What Painpoint DCI Aims to Solve The Gang of Four Book object-composition Mailing List (Google Group) 09:31 - Designing From DCI From the Start (Process) Levels of Use Cases Writing Effective Use Cases by Alistair Cockburn 11:42 - Object Composition Single Responsibility Principle 13:56 - Definitions: Forwarding, Delegation, Consultation, and Inheritance Class-Based Inheritance vs Prototype-Based Inheritance JavaScript Influence 18:37 - DCI and Service Objects Context 24:36 - Roles and Object Factoring Authentication 28:49 - One Context in a Single File surrounded 30:17 - Coupling and Cohesion 31:37 - Typeclasses 33:09 - DCI Criticism casting 36:51 - The Current State of DCI (Skepticism & Criticism?) Domain-Driven Design 38:56 - Preventing Reuse 41:18 - When should you not use DCI? 43:45 - Transition: Using/Undoing DCI (Experimentation) 45:04 - Resources fulloo.info Marvin object-composition Mailing List (Google Group) Clean Ruby More DCI Blog Posts by Jim Delegation Is Everything And Inheritance Does Not Exist Chubby Models Are Still Fat With Concerns. DCI Focuses On How Things Work Together The Gang Of Four Is Wrong And You Don't Understand Delegation Triggering The DCI Context OOP, DCI And Ruby - What Your System Is Vs. What Your System Does 4 Simple Steps - Extending Ruby Objects - The Tip Of The Iceberg With DCI Picks Richard Hamming: You and Your Research (Jessica) Martin Fowler: Yagni (Coraline) Ruby Monday (Saron) JunkFill (Saron) Wappalyzer (Saron) WhatFont (Saron) Julian Feliciano: What Is Source Control? (Saron) Bodum Santos Stovetop Glass Vacuum 34-Ounce Coffee Maker (Avdi) The Master and His Emissary: The Divided Brain and the Making of the Western World by Iain McGilchrist (Jim) request_store_rails (Jim) littleBits (Jim)

master data single blog gang levels context solve roles criticism solid inheritance current state delegation object github interaction domain consultation use cases western world authentication creativeasin cohesion coupling oop dci design patterns iain mcgilchrist domain driven design saron littlebits avdi alistair cockburn yagni solid principles single responsibility principle your research jim gay

211 RR DCI with Jim Gay

Play Episode Listen Later Jun 10, 2015 55:50

02:48 - Jim Gay Introduction Twitter GitHub Blog Ruby DSL Handbook 03:43 - Object Design Clean Ruby SOLID Principles 04:39 - DCI (Data, Context, Interaction) Main Resource for DCI (FullOO) 07:20 - What Painpoint DCI Aims to Solve The Gang of Four Book object-composition Mailing List (Google Group) 09:31 - Designing From DCI From the Start (Process) Levels of Use Cases Writing Effective Use Cases by Alistair Cockburn 11:42 - Object Composition Single Responsibility Principle 13:56 - Definitions: Forwarding, Delegation, Consultation, and Inheritance Class-Based Inheritance vs Prototype-Based Inheritance JavaScript Influence 18:37 - DCI and Service Objects Context 24:36 - Roles and Object Factoring Authentication 28:49 - One Context in a Single File surrounded 30:17 - Coupling and Cohesion 31:37 - Typeclasses 33:09 - DCI Criticism casting 36:51 - The Current State of DCI (Skepticism & Criticism?) Domain-Driven Design 38:56 - Preventing Reuse 41:18 - When should you not use DCI? 43:45 - Transition: Using/Undoing DCI (Experimentation) 45:04 - Resources fulloo.info Marvin object-composition Mailing List (Google Group) Clean Ruby More DCI Blog Posts by Jim Delegation Is Everything And Inheritance Does Not Exist Chubby Models Are Still Fat With Concerns. DCI Focuses On How Things Work Together The Gang Of Four Is Wrong And You Don't Understand Delegation Triggering The DCI Context OOP, DCI And Ruby - What Your System Is Vs. What Your System Does 4 Simple Steps - Extending Ruby Objects - The Tip Of The Iceberg With DCI Picks Richard Hamming: You and Your Research (Jessica) Martin Fowler: Yagni (Coraline) Ruby Monday (Saron) JunkFill (Saron) Wappalyzer (Saron) WhatFont (Saron) Julian Feliciano: What Is Source Control? (Saron) Bodum Santos Stovetop Glass Vacuum 34-Ounce Coffee Maker (Avdi) The Master and His Emissary: The Divided Brain and the Making of the Western World by Iain McGilchrist (Jim) request_store_rails (Jim) littleBits (Jim)

master data single blog gang levels context solve roles criticism solid inheritance current state delegation object github interaction domain consultation use cases western world authentication creativeasin cohesion coupling oop dci design patterns iain mcgilchrist domain driven design saron littlebits avdi alistair cockburn yagni solid principles single responsibility principle your research jim gay

210 RR Roda and Routing Trees with Jeremy Evans

Play Episode Listen Later Jun 3, 2015 72:56

Sign up for Ruby Remote Conf!! 02:49 - Jeremy Evans Introduction Twitter GitHub Blog Sequel Ruby Hero Awards 03:58 - Roda and Routing Trees rum Cuba Ruby Rogues Episode #182: Keeping Libraries and Utilities Small and Simple with Michel Martens Plugins: ClassLevelRouting 08:56 - Roda vs Padrino, Sinatra 10:03 - Nested Routing 11:09 - Snipping Routing Trees? MultiRoute 13:19 - Dispatching from One Rack Application to Another 13:54 - Rails Integration 14:33 - Performance and Benchmarking @tenderlove (Aaron Patterson) nyny r10k bench-micro 17:29 - Streaming reel 19:26 - Support Decisions (Roadmapping) Opal More on Opal: Ruby Rogues Episode #193: The Volt Framework with Ryan Stout tilt The Changelog Episode #154: All Things Ruby with 2015’s Ruby Heroes 22:05 - Plugin Architecture Sequel The Single Responsibility Principle roda/lib/roda/plugins at master 28:00 - Security Ruby Rogues Episode #207: Rebuilding Rails with Noah Gibbs DefaultHeaders 30:17 - Apps That Work Well with Roda and Using Roda 33:16 - Application Freezing 36:12 - Jeremy’s Typical Stack/Workflow 37:30 - When Should You Not Use Roda? 38:39 - Roda Timeline and Roadmap 40:01 - Jeremy’s Work/Life Balance OpenBSD 43:46 - Open Source Getting Paid Picking a Project 49:03 - Application Optimization Big O Notation 57:00 - Routing Approaches The Annotated C++ Reference Manual by Ellis and Stroustrup Picks Self: The Movie; (Avdi) Self and Self: Whys and Wherefores (Avdi) April Fools Video Prank in Math Class (Saron) A pattern language for microservices (Coraline) Wytches (Coraline) Garmin Vivosmart (David) "REDNECK AVENGERS: TULSA NIGHTS" — A Bad Lip Reading of Marvel's The Avengers (David) CodeNewbie Episode #37: From Skates To Code with Aimee Knight (Chuck) This Is Your Life Podcast (Chuck) Cleaning off your desk (Chuck) Ys (Jeremy) minjs (Jeremy) Camp (2013) (Jeremy)

project marvel performance simple single open blog security camp streaming cuba avengers trees picking integration work life balance application sequels roadmap cleaning frank sinatra open source github rails getting paid rack big o plugins benchmarking routing ys padrino saron wytches math class dispatching jeremy evans openbsd bad lip reading avdi ryan stout aaron patterson aimee knight big o notation single responsibility principle ruby rogues episode ruby remote conf

210 RR Roda and Routing Trees with Jeremy Evans

Play Episode Listen Later Jun 3, 2015 72:56

Sign up for Ruby Remote Conf!! 02:49 - Jeremy Evans Introduction Twitter GitHub Blog Sequel Ruby Hero Awards 03:58 - Roda and Routing Trees rum Cuba Ruby Rogues Episode #182: Keeping Libraries and Utilities Small and Simple with Michel Martens Plugins: ClassLevelRouting 08:56 - Roda vs Padrino, Sinatra 10:03 - Nested Routing 11:09 - Snipping Routing Trees? MultiRoute 13:19 - Dispatching from One Rack Application to Another 13:54 - Rails Integration 14:33 - Performance and Benchmarking @tenderlove (Aaron Patterson) nyny r10k bench-micro 17:29 - Streaming reel 19:26 - Support Decisions (Roadmapping) Opal More on Opal: Ruby Rogues Episode #193: The Volt Framework with Ryan Stout tilt The Changelog Episode #154: All Things Ruby with 2015’s Ruby Heroes 22:05 - Plugin Architecture Sequel The Single Responsibility Principle roda/lib/roda/plugins at master 28:00 - Security Ruby Rogues Episode #207: Rebuilding Rails with Noah Gibbs DefaultHeaders 30:17 - Apps That Work Well with Roda and Using Roda 33:16 - Application Freezing 36:12 - Jeremy’s Typical Stack/Workflow 37:30 - When Should You Not Use Roda? 38:39 - Roda Timeline and Roadmap 40:01 - Jeremy’s Work/Life Balance OpenBSD 43:46 - Open Source Getting Paid Picking a Project 49:03 - Application Optimization Big O Notation 57:00 - Routing Approaches The Annotated C++ Reference Manual by Ellis and Stroustrup Picks Self: The Movie; (Avdi) Self and Self: Whys and Wherefores (Avdi) April Fools Video Prank in Math Class (Saron) A pattern language for microservices (Coraline) Wytches (Coraline) Garmin Vivosmart (David) "REDNECK AVENGERS: TULSA NIGHTS" — A Bad Lip Reading of Marvel's The Avengers (David) CodeNewbie Episode #37: From Skates To Code with Aimee Knight (Chuck) This Is Your Life Podcast (Chuck) Cleaning off your desk (Chuck) Ys (Jeremy) minjs (Jeremy) Camp (2013) (Jeremy)

project marvel performance simple single open blog security camp streaming cuba avengers trees picking integration work life balance application sequels roadmap cleaning frank sinatra open source github rails getting paid rack big o plugins benchmarking routing ys padrino saron wytches math class dispatching jeremy evans openbsd bad lip reading avdi ryan stout aaron patterson aimee knight big o notation single responsibility principle ruby rogues episode ruby remote conf

210 RR Roda and Routing Trees with Jeremy Evans

Play Episode Listen Later Jun 3, 2015 72:56

Sign up for Ruby Remote Conf!! 02:49 - Jeremy Evans Introduction Twitter GitHub Blog Sequel Ruby Hero Awards 03:58 - Roda and Routing Trees rum Cuba Ruby Rogues Episode #182: Keeping Libraries and Utilities Small and Simple with Michel Martens Plugins: ClassLevelRouting 08:56 - Roda vs Padrino, Sinatra 10:03 - Nested Routing 11:09 - Snipping Routing Trees? MultiRoute 13:19 - Dispatching from One Rack Application to Another 13:54 - Rails Integration 14:33 - Performance and Benchmarking @tenderlove (Aaron Patterson) nyny r10k bench-micro 17:29 - Streaming reel 19:26 - Support Decisions (Roadmapping) Opal More on Opal: Ruby Rogues Episode #193: The Volt Framework with Ryan Stout tilt The Changelog Episode #154: All Things Ruby with 2015’s Ruby Heroes 22:05 - Plugin Architecture Sequel The Single Responsibility Principle roda/lib/roda/plugins at master 28:00 - Security Ruby Rogues Episode #207: Rebuilding Rails with Noah Gibbs DefaultHeaders 30:17 - Apps That Work Well with Roda and Using Roda 33:16 - Application Freezing 36:12 - Jeremy’s Typical Stack/Workflow 37:30 - When Should You Not Use Roda? 38:39 - Roda Timeline and Roadmap 40:01 - Jeremy’s Work/Life Balance OpenBSD 43:46 - Open Source Getting Paid Picking a Project 49:03 - Application Optimization Big O Notation 57:00 - Routing Approaches The Annotated C++ Reference Manual by Ellis and Stroustrup Picks Self: The Movie; (Avdi) Self and Self: Whys and Wherefores (Avdi) April Fools Video Prank in Math Class (Saron) A pattern language for microservices (Coraline) Wytches (Coraline) Garmin Vivosmart (David) "REDNECK AVENGERS: TULSA NIGHTS" — A Bad Lip Reading of Marvel's The Avengers (David) CodeNewbie Episode #37: From Skates To Code with Aimee Knight (Chuck) This Is Your Life Podcast (Chuck) Cleaning off your desk (Chuck) Ys (Jeremy) minjs (Jeremy) Camp (2013) (Jeremy)

project marvel performance simple single open blog security camp streaming cuba avengers trees picking integration work life balance application sequels roadmap cleaning frank sinatra open source github rails getting paid rack big o plugins benchmarking routing ys padrino saron wytches math class dispatching jeremy evans openbsd bad lip reading avdi ryan stout aaron patterson aimee knight big o notation single responsibility principle ruby rogues episode ruby remote conf

206 RR Trailblazer with Nick Sutterer

Play Episode Listen Later May 6, 2015 52:14

02:53 - Nick Sutterer Introduction Twitter GitHub Blog Trailblazer: A New Architecture For Rails by Nick Sutterer 03:31 - Trailblazer [GitHub] trailblazer 04:56 - Form Object “Operation” 07:28 - Validations ActiveModel::Validations lotus/validations Introducing Lotus::Validations 08:47 - Decoupling 09:45 - Namespace Reuse Concepts/Concerns 11:50 - Process Method => Procedural Code 12:54 - Inheritance 13:57 - Contracts 14:57 - How is Using Trailblazer Different? 18:17 - What Would DHH Think? 19:32 - Trailblazer as an Extra Layer Single Responsibility Principle Monoliths RailsConf 2015: David Heinemeier Hansson Keynote 27:20 - Testing 28:35 - When Should You NOT Use Trailblazer? 29:53 - Moving to Trailblazer 36:03 - Rails 5 and Trailblazer 37:22 - Maintainers Abdelkader Boudih Celso Fernandes 38:44 - APIs Deserialization 41:04 - Parts of Trailblazer reform roar cells 44:16 - Generators Picks A Gentleman’s Guide To Street Harassment (Saron) Tor and HTTPS (Saron) How it feels to watch a user test your product for the first time (Saron) Humane Development (Coraline) The Left Hand of Darkness (Coraline) Star Wars: Episode VII - The Force Awakens (Chuck) WorkFlowy (Chuck) Ruby Rogues Episode #204: Limerence with Dave Thomas (Chuck) JS Remote Conf Talks (Chuck) Trailblazer: A New Architecture For Rails by Nick Sutterer (Nick) [YouTube] Cinco Face Time Party Snoozer (Nick)

moving development single darkness blog testing operation inheritance contracts gentleman tor github apis trailblazer rails humane generators left hand decoupling dave thomas monoliths what would star wars episode vii the force awakens dhh limerence saron abdelkader maintainers validations workflowy railsconf deserialization single responsibility principle ruby rogues episode

206 RR Trailblazer with Nick Sutterer

Play Episode Listen Later May 6, 2015 52:14

02:53 - Nick Sutterer Introduction Twitter GitHub Blog Trailblazer: A New Architecture For Rails by Nick Sutterer 03:31 - Trailblazer [GitHub] trailblazer 04:56 - Form Object “Operation” 07:28 - Validations ActiveModel::Validations lotus/validations Introducing Lotus::Validations 08:47 - Decoupling 09:45 - Namespace Reuse Concepts/Concerns 11:50 - Process Method => Procedural Code 12:54 - Inheritance 13:57 - Contracts 14:57 - How is Using Trailblazer Different? 18:17 - What Would DHH Think? 19:32 - Trailblazer as an Extra Layer Single Responsibility Principle Monoliths RailsConf 2015: David Heinemeier Hansson Keynote 27:20 - Testing 28:35 - When Should You NOT Use Trailblazer? 29:53 - Moving to Trailblazer 36:03 - Rails 5 and Trailblazer 37:22 - Maintainers Abdelkader Boudih Celso Fernandes 38:44 - APIs Deserialization 41:04 - Parts of Trailblazer reform roar cells 44:16 - Generators Picks A Gentleman’s Guide To Street Harassment (Saron) Tor and HTTPS (Saron) How it feels to watch a user test your product for the first time (Saron) Humane Development (Coraline) The Left Hand of Darkness (Coraline) Star Wars: Episode VII - The Force Awakens (Chuck) WorkFlowy (Chuck) Ruby Rogues Episode #204: Limerence with Dave Thomas (Chuck) JS Remote Conf Talks (Chuck) Trailblazer: A New Architecture For Rails by Nick Sutterer (Nick) [YouTube] Cinco Face Time Party Snoozer (Nick)

moving development single darkness blog testing operation inheritance contracts gentleman tor github apis trailblazer rails humane generators left hand decoupling dave thomas monoliths what would star wars episode vii the force awakens dhh limerence saron abdelkader maintainers validations workflowy railsconf deserialization single responsibility principle ruby rogues episode

206 RR Trailblazer with Nick Sutterer

Giant Robots Smashing Into Other Giant Robots

Play Episode Listen Later May 6, 2015 52:14

02:53 - Nick Sutterer Introduction Twitter GitHub Blog Trailblazer: A New Architecture For Rails by Nick Sutterer 03:31 - Trailblazer [GitHub] trailblazer 04:56 - Form Object “Operation” 07:28 - Validations ActiveModel::Validations lotus/validations Introducing Lotus::Validations 08:47 - Decoupling 09:45 - Namespace Reuse Concepts/Concerns 11:50 - Process Method => Procedural Code 12:54 - Inheritance 13:57 - Contracts 14:57 - How is Using Trailblazer Different? 18:17 - What Would DHH Think? 19:32 - Trailblazer as an Extra Layer Single Responsibility Principle Monoliths RailsConf 2015: David Heinemeier Hansson Keynote 27:20 - Testing 28:35 - When Should You NOT Use Trailblazer? 29:53 - Moving to Trailblazer 36:03 - Rails 5 and Trailblazer 37:22 - Maintainers Abdelkader Boudih Celso Fernandes 38:44 - APIs Deserialization 41:04 - Parts of Trailblazer reform roar cells 44:16 - Generators Picks A Gentleman’s Guide To Street Harassment (Saron) Tor and HTTPS (Saron) How it feels to watch a user test your product for the first time (Saron) Humane Development (Coraline) The Left Hand of Darkness (Coraline) Star Wars: Episode VII - The Force Awakens (Chuck) WorkFlowy (Chuck) Ruby Rogues Episode #204: Limerence with Dave Thomas (Chuck) JS Remote Conf Talks (Chuck) Trailblazer: A New Architecture For Rails by Nick Sutterer (Nick) [YouTube] Cinco Face Time Party Snoozer (Nick)

moving development single darkness blog testing operation inheritance contracts gentleman tor github apis trailblazer rails humane generators left hand decoupling dave thomas monoliths what would star wars episode vii the force awakens dhh limerence saron abdelkader maintainers validations workflowy railsconf deserialization single responsibility principle ruby rogues episode

10: Isn't the last stage of grieving acceptance?

Play Episode Listen Later Sep 2, 2012 43:03

Ben Orenstein is joined by Joe Ferris and Mike Burns. They start off with some recommendations for awesome programming books and then dive right in to questions about not following "Tell don't ask" in the view, how MVC and the Single Responsibility Principle may be at odds with "Tell don't ask" in the view, and what a more object oriented approach may look like. They also discuss "Class-oriented programming", what it is, why it is bad, how Rails does it, and how to avoid it. They take a quick trip through Mike's experiments in Ruby and Smalltalk in creating his own programming language. The three codecateers then take on the really important topic of method order and code organization, and finally they reflect on how their code has changed over the years, how no solution is foolproof, and how to move to the next level as a programmer. These topics and more, in this installment of the GIANT ROBOTS SMASHING INTO OTHER GIANT ROBOTS podcast! Structure and Interpretation of Computer Programs MIT course that everyone failed Growing Object-Oriented Software, Guided by Tests Clean Code: A Handbook of Agile Software Craftsmanship Tell Don't Ask Single Responsibility Principle Shotgun Surgery Smalltalk, Squeak Scala, Play framework Follow @thoughtbot, @r00k, @joeferris, @mikeburns on twitter.

mit single class stage acceptance structure tests guided grieving interpretation small talk rails shotgun scala squeak mvc mike burns ben orenstein computer programs agile software craftsmanship single responsibility principle clean code a handbook

ActiveRecord Observers