What is the right "unit" in unit testing and why it is not a class?
•Transferir como PPTX, PDF•
0 gostou•160 visualizações
Whether you're just writing your first unit test or have been practicing Test Driven Development for many years, I'm sure your biggest challenge is to find the right scope for testing. Unfortunately a lot of books and guidance seem to imply that every class or type should be tested separately. Well, I can tell you from 15 years of unit testing experience that that's the best way to shoot yourself in the foot. In this session, I'm going to show you some concrete examples and why I chose a certain boundary for the "unit" in unit testing. I will also share design heuristics I use myself to find those boundaries and why those are not guidelines. I'll also illustrate how principals like DRY and SOLID can be both a blessing and a curse that may lead to the wrong design choices.
Denunciar
Compartilhar
Denunciar
Compartilhar
Recomendados
Getting a grip on your code dependencies
I'm sure every developer wants to be able to change code with confidence and without fear. Readable and self-explanatory code is one aspect of that. Too much coupling is another major source of problems that prevent you from changing one part of the system without causing side-effects. In this talk, I'd like you to show you common sources of unnecessary coupling and offer you options to help prevent and/or break those. I'll talk about how principles like Don't Repeat Yourself and Dependency Injection can be a double-edge sword, how to detect too unnecessary dependencies and how to use the Dependency Inversion Principle to unravel some of those. And yes, I will also talk about controlling dependencies on the package level.
What is the right unit in unit testing (UpdateConf 2022)
Whether you're just writing your first unit test or have been practicing Test Driven Development for many years, I'm sure your biggest challenge is to find the right scope for testing. Unfortunately a lot of books and guidance seem to imply that every class or type should be tested separately. Well, I can tell you from 15 years of unit testing experience that that's the best way to shoot yourself in the foot.
In this session, I'm going to show you some concrete examples and why I chose a certain boundary for the "unit" in unit testing. I will also share design heuristics I use myself to find those boundaries and why those are not guidelines. I'll also illustrate how principals like DRY and SOLID can be both a blessing and a curse that may lead to the wrong design choices
50 things software teams should not do.pptx
The document discusses 50 things that software teams should avoid doing related to architecture, code design, testability, documentation, team maturity and process. Some examples include treating a monolith as inherently bad, using microservices as an escape plan from technical debt, dogmatically using design patterns, insufficient test coverage, messy source control history, developers working in isolation, artificial sprint goals, and long-running stand-ups. The document is written by Dennis Doomen, an architect with 25 years of experience in the .NET space.
Up to speed in domain driven design
This document discusses Domain Driven Design (DDD). It provides an overview of DDD, including that it focuses on removing translation barriers between a domain, development team, and software design. It also describes common building blocks of domain models such as entities, value objects, factories, repositories, and services. Additionally, it discusses refactoring a model to gain deeper insight, including making implicit concepts explicit.
Ian Cooper webinar for DDD Iran: Kent beck style tdd seven years after
Ian Cooper webinar for DDD Iran: Kent beck style tdd seven years afterIranian Domain-Driven Design Community
The original promise of TDD was that it would assist in guiding the development of clean code, but it often ends up polluting our architecture with excessive composition, is expensive to write, and becomes an obstacle to change, not an aid to refactoring. In this talk, we look at the fallacies of TDD and learn about the key principles that we should be following for mastery of this practice. This talk is intended for those who have been practicing TDD, or who have tried TDD and given up because of shortcomings in the approach they were taught.Test Driven Development - Overview and Adoption
Test-driven development (TDD) is a software development technique where unit tests are written before code to define desired functionality. Writing tests first helps produce code with better design, lower maintenance costs, and fewer bugs. Key principles of TDD include writing code only to pass failing tests and eliminating duplication. Benefits include better test coverage, easier refactoring, and preventing regressions. TDD helps developers act as users to define behavior through interactions between system components.
Software as a Service
As programmers, we provide a service to our customers. To create the best possible experience for a customer, we must adhere to our values and beliefs.
Recomendados
Getting a grip on your code dependencies
I'm sure every developer wants to be able to change code with confidence and without fear. Readable and self-explanatory code is one aspect of that. Too much coupling is another major source of problems that prevent you from changing one part of the system without causing side-effects. In this talk, I'd like you to show you common sources of unnecessary coupling and offer you options to help prevent and/or break those. I'll talk about how principles like Don't Repeat Yourself and Dependency Injection can be a double-edge sword, how to detect too unnecessary dependencies and how to use the Dependency Inversion Principle to unravel some of those. And yes, I will also talk about controlling dependencies on the package level.
What is the right unit in unit testing (UpdateConf 2022)
Whether you're just writing your first unit test or have been practicing Test Driven Development for many years, I'm sure your biggest challenge is to find the right scope for testing. Unfortunately a lot of books and guidance seem to imply that every class or type should be tested separately. Well, I can tell you from 15 years of unit testing experience that that's the best way to shoot yourself in the foot.
In this session, I'm going to show you some concrete examples and why I chose a certain boundary for the "unit" in unit testing. I will also share design heuristics I use myself to find those boundaries and why those are not guidelines. I'll also illustrate how principals like DRY and SOLID can be both a blessing and a curse that may lead to the wrong design choices
50 things software teams should not do.pptx
The document discusses 50 things that software teams should avoid doing related to architecture, code design, testability, documentation, team maturity and process. Some examples include treating a monolith as inherently bad, using microservices as an escape plan from technical debt, dogmatically using design patterns, insufficient test coverage, messy source control history, developers working in isolation, artificial sprint goals, and long-running stand-ups. The document is written by Dennis Doomen, an architect with 25 years of experience in the .NET space.
Up to speed in domain driven design
This document discusses Domain Driven Design (DDD). It provides an overview of DDD, including that it focuses on removing translation barriers between a domain, development team, and software design. It also describes common building blocks of domain models such as entities, value objects, factories, repositories, and services. Additionally, it discusses refactoring a model to gain deeper insight, including making implicit concepts explicit.
Ian Cooper webinar for DDD Iran: Kent beck style tdd seven years after
Ian Cooper webinar for DDD Iran: Kent beck style tdd seven years afterIranian Domain-Driven Design Community
The original promise of TDD was that it would assist in guiding the development of clean code, but it often ends up polluting our architecture with excessive composition, is expensive to write, and becomes an obstacle to change, not an aid to refactoring. In this talk, we look at the fallacies of TDD and learn about the key principles that we should be following for mastery of this practice. This talk is intended for those who have been practicing TDD, or who have tried TDD and given up because of shortcomings in the approach they were taught.Test Driven Development - Overview and Adoption
Test-driven development (TDD) is a software development technique where unit tests are written before code to define desired functionality. Writing tests first helps produce code with better design, lower maintenance costs, and fewer bugs. Key principles of TDD include writing code only to pass failing tests and eliminating duplication. Benefits include better test coverage, easier refactoring, and preventing regressions. TDD helps developers act as users to define behavior through interactions between system components.
Software as a Service
As programmers, we provide a service to our customers. To create the best possible experience for a customer, we must adhere to our values and beliefs.
Test-Driven Development
Test-driven development (TDD) is a software development process that relies on the repetition of a short development cycle of requirements, design, and coding. It promotes writing tests before writing code (test-first design) and helps improve code quality by reducing defects. The TDD cycle involves writing an automated test, running the test and seeing it fail, writing the minimum amount of code to pass the test, and refactoring the code as needed. TDD brings benefits like clarifying requirements, adding executable documentation, and detecting errors early. Acceptance TDD involves automating acceptance tests to define and validate requirements. It helps establish a definition of done and improves team collaboration.
16 things a developer should know about testing
“Do you know a good book about testing software, Wolf?” “Err… actually I don’t. But I know a few things about testing I am happy to share…”
This is how it all started. In this session, Wolf is sharing battle hands-on and battle proven approaches to ensuring that quality is baked into our software from day one.
Learn about the limitations of test driven design, how to test asynchronous behaviour and the merits of bug bashing (just to name a few).
Bio: Wolf is a professionally qualified software engineer with over 20 years of international consulting experience. He works for ThoughtWorks Germany and helps teams delivering working software.
Wolf's primary professional interests are microservices, cloud, continuous delivery, agile enablement and humanitarian software.
TDD Flow: The Mantra in Action
San Francisco Software Craftsmanship Meetup
Test Driven Developers Bay Area Meetup
TDD Flow: The Mantra in Action” is a talk + hands-on about the mantra of TDD and its core patterns. Here are some questions for this talk: What is TDD? How to write a good test that fails? How to write code enough to make the test pass? How to remove duplication? How to refactor code? How to create clean code? Is TDD about testing or design? How small should a test be? Should I only write unit tests? Should I estimate TDD? How to use TDD with other agile methods like Scrum, Kanban or BDD? And finally, how to flow in TDD?
Tdd and-design-draft
The document discusses how test-driven development (TDD) influences class design from the perspective of a practitioner. TDD encourages developers to write easily testable code, which leads to low coupled and highly cohesive classes that follow good object-oriented design principles. Specifically, TDD helps reduce class coupling by making dependencies explicit, focusing on stable abstractions rather than implementations, and avoiding overly complex "god classes." It also improves cohesion by encouraging small specialized classes and composing behaviors through patterns like factories and observers. The practitioner argues that while TDD provides useful feedback on design, it ultimately relies on developers recognizing issues and applying their skills and experience to address them.
Test Driven Development
The document discusses test-driven development (TDD) and design-driven development (DDD). It advocates for writing tests before code using short iterative development cycles. TDD helps produce clean code that fulfills requirements by making developers think about required behavior, providing documentation, and improving quality. Common objections to TDD are addressed, noting that it forces understanding of code and tests, creates reusable modular code, and drives simplicity. Guidelines for effective TDD include writing small focused tests with descriptive intentions that are independent and repeatable.
Extreme Programming: An Introduction to XP Practices
This document provides an overview of the twelve core Extreme Programming (XP) practices introduced by Kent Beck in his 1999 book Extreme Programming Explained. It discusses each practice in 1-2 paragraphs, including planning games, small releases, sustainable pace, whole team, testing, pair programming, coding standards, continuous integration, system metaphor, simple design, refactoring, and collective ownership. The presentation was given by David Hanson, who has experience adopting and integrating XP practices into Agile projects following Scrum and Kanban methodologies.
Introduction to Extreme Programming
This document provides an introduction and overview of eXtreme Programming (XP), an agile software development methodology. It discusses what XP is, its history and origins, core values and principles, practices, and components like the whole XP team. Key aspects of XP covered include pair programming, short development cycles, test-first development, simple design, frequent integration and feedback. The document aims to explain the philosophy and mechanics of the XP methodology.
JavaScript Unit Testing
Presentation developed for JSChannel BLR :: Meetup 8 - Unit testing AngularJS using Jasmine and Karma
Agile principles and practices
Agile * Agile Principles * Agile Practices * Pair Programming * Extreme Programming * SOLID design principles * SDLC * Software Development
After working 10 years in multiple major "from-scratch" development projects, I finally got a chance to work in a truly Agile development project. Here is my take on how to make Agile work for your project.
Pair Programming Talk
This document summarizes the benefits and mechanics of pair programming. It discusses that all production software should be developed by two programmers working jointly, switching pairs frequently. The benefits include continual code review, improved design quality, fewer defects, more rapid solutions, improved communication among team members, and reduced risk. Potential issues that can arise include difficulties with introverts, experts paired with novices, and individuals who refuse to pair program.
The Test Case as Executable Example
The document discusses test cases as executable examples that communicate requirements and system behavior throughout the development cycle. It notes challenges like incomplete or overly large example sets and disconnected examples. The document proposes measuring test case similarity to help understand test suites and group examples. Preliminary evaluation of a technique to rank test cases by similarity showed it could help explain surprises in a test suite. Rethinking test cases as examples and developing languages to write different levels of executable, analyzable, and connected examples is suggested.
Design patterns for Event Sourcing in .NET
Event Sourcing is becoming more mainstream these days, and a lot of conferences have demonstrated the pros and cons of this architecture style from multiple angles. I've done a few of these and publishes a lot of articles on best practices and solutions to common problems. But what nobody did was to show you how to build an event sourced systems in the .NET ecosystem. There are a lot of open-source projects that you can use, so you'll need to find a right mix and your own code to that. So let me show you how I would implement this in .NET with almost 10 years of Event Sourcing experience behind my belt.
My Laws of Test Driven Development (2023)
About 15 years ago, I got inspired by a series of posts on Test Driven Development written by the Jeremy D. Miller. Now, with many years of great and not-so-great experiences practicing Test Driven Development, I thought it is the time to capture my own “laws”. The term "law" is obviously an exaggeration and "principles or heuristics" cover my intend much better. Either way, I want to talk about the scope of testing, using the observable behavior, naming conventions, state-based vs interaction-based testing, the impact of DRY, patterns to build useful test objects and some of the libraries and tools I use. In short, everything I try to follow every day I write, review or maintain code.
Effective unit testing
The document discusses effective unit testing. It covers topics like the value of writing tests, test-driven development, behavior-driven development, test doubles, structuring tests with arrange-act-assert/given-when-then, checking behavior not implementation, test smells, JUnit basics, and parameterized testing. The goal of tests is to validate code behavior, catch mistakes, and shape design. Writing tests also helps learn what the code is intended to do.
Test-Driven Design - ¿Porqué?
The document discusses test-driven development (TDD) and how it can be used to reduce unnecessary complexity, also known as inventory, in software design. TDD involves writing automated tests before code to articulate requirements and ensure only needed code is written. It promotes designing simple, clear code without duplication through principles like You Aren't Gonna Need It and refactoring code in small, reversible steps. Following TDD principles is claimed to reduce inventory created by excess complexity and allow designs to evolve incrementally based on test feedback.
No more Three Tier - A path to a better code for Cloud and Azure
Three Tier is no more a model for Cloud and in general Scalable Web Applications. Scaffolding from SQL Database is, sure, the worst way to do. A road to do this is changing modeling activity, from scaffolded DB model to Command/DTO model, through ViewModel pattern. Command and DTOs are pillars of CQRS model.
Test Driven Development
This document discusses test-driven development (TDD), an approach where unit tests are written before production code to specify functionality. With TDD, developers first write a failing unit test, then produce just enough code to pass that test, and refactor as needed. Key principles are to only write production code to pass tests and not write more of a test than needed to fail initially. TDD is claimed to produce robust code, enable continuous deployment, and allow releasing at any time due to test coverage, though it has a learning curve and time costs. Various testing frameworks and runners that support TDD are also listed.
Software Design for Testability
This document discusses design for testability. It defines testability as having controllability and visibility. Controllability is the ability to apply inputs and place a system in specified states, while visibility is the ability to observe states and outputs. The document outlines why testability is important for improving quality and reducing costs. It describes how to achieve testability through good design practices like abstraction, encapsulation, and avoiding interdependence. Testability features like logging and assertions are also recommended. Development techniques like defensive programming, design by contract, and test-driven development can further enhance testability.
Importance Of Being Driven
The importance to be Driven
There are many buzzwords and acronyms to describe how the software should be designed. TDD (Test Driven), BDD (Behaviour Driven), DDD (Domain Driven) are the most well known. In this speech we'll run thought all these techniques comparing each one of those with TDD and finding what are the common concepts. An exercise will show to the students how different the code will be using different design methodologies as driver.
Human computer interaction research at ibm t
The document describes a study that compared the effectiveness of two approaches to online learning - a custom course assembly approach that dynamically assembled learning objects, and a query engine approach. Subjects using the custom course assembly produced more extensive designs for a given task and performed better based on expert evaluations, even after accounting for differences in experience. The custom course approach may have led to better performance by encouraging focus, providing more relevant content, and creating a more organized learning experience.
Getting a grip on your code dependencies (2023-10)
I'm sure every developer wants to be able to change code with confidence and without fear. Readable and self-explanatory code is one aspect of that. Too much coupling is another major source of problems that prevent you from changing one part of the system without causing side-effects. In this talk, I'd like you to show you common sources of unnecessary coupling and offer you options to help prevent and/or break those. I'll talk about how principles like Don't Repeat Yourself and Dependency Injection can be a double-edge sword, how to detect too unnecessary dependencies and how to use the Dependency Inversion Principle to unravel some of those. And yes, I will also talk about controlling dependencies on the package level.
Challenge
1. How to prevent too much coupling?
2. We are tought to decrease coupling and increase cohesion
3. How do you increase cohesion? By applying DRY!
4. But DRY creates more coupling
5. And too much decoupling results in a forest of abstractions
6. The solution is… find a balance (or "it depends")
On the architecture level
1. Use architecture style that embraces DIP (e.g. Onion, Hexagon, Clean Architecture)
2. Organize your code along functional boundaries -> this will make it easier to break off that boundary for rebuilding/strangler/microservices.
3. Apply DRY within those boundaries only, but allow shared services for complicated capabilities
4. Align your test scope with those internal boundaries…
On the package level
• Classes and interfaces that are almost always used together should be packaged together. Those that don’t meet that criteria don’t have a place in that package
• Packages should not require changes (and thus a new release) for unrelated changes.
• There must be no cycles in the dependency structure
• A package should only depend upon packages that are more stable than it is or abstract packages
On the code level
• Avoid technical folders and organize them by functionalities or capabilities
• Things in adjacent folders usually mean they are separate boundaries
• Use the Tell, Don't Ask principle
• Use the Law of Demeter to detect unnecessary coupling
• Encapsulate primitive types and collections in specific types
• Dependency injection is great, but try to avoid a global container
• It's fine to inject concrete classes inside boundaries
Strategy for legacy code
1. Ensure you have a safety net using characterisation tests
2. Find existing seams and decouple them better
a. Identify modules or functional slices
b. Identify groups of classes that are supposed to be used together and are designed to be reusable
c. Identify interfaces or abstractions in DI registration code and see if they are truly designed for reusability
d. Assume that code in adjacent folders is supposed to be independent
e. Move code from different technical folders that belong together in their own (functionally named) folderPublic
3. Use that to define (and visualize) the target architecture
Tools and practices to help you deal with legacy code
We all love to build greenfield projects, but the reality is that in most jobs you have to deal with a lot of legacy code. This doesn't mean the code is bad. It just means that choices were made that were the right ones at that time, or that the developers were not entire up-to-date with modern development practices. And that's exactly what this talk is about. I enjoy taking such a codebase and gradually introduce architectural seems, add a proper build pipeline, introduce temporary tests and then gradually refactor the codebase to combine more maintainable, testable and reliable. So in this talk, I'd like to unfold my extensive toolbox of practices, principles, tools and mindset to help you improve your legacy code without jeopardizing your business.
Understand production environment
See which vinaries are running in production and what config files are used
Verify the code and the production release are in sync, e.g. DotPeek
Analyze logs to understand what features are used
Try to get it to run on a local environment
Understand code
Generate project diagrams and class hierarchies
Find origin calls and destination of a parameter using Rider
Use navigation options to find inheritors, usages, etc.
Use the namespaces and project names to understand the relation
Have Rider's AI Assistant or ChatGPT explain the code
Track all documentation in a single place
Build C4 diagrams
Find dead code
Reduce the scope of types and members to internal to find more dead code
Detect code inefficiencies and dead code using Rider
Remove commented out code
Build a safety net
If therea are tests, add code coverage reporting using Coverlet and use that to find dark spots
(HTTP API) Characteristics tests using FluentAssertions, Bogus, xUnit. Use AI to generate them. It's fine, you'll delete them later on
Use test containers for .net t lo include the databse
Build a couple of end to end UI tests e.g. using Cypress, Playwright, efc
Improve deployability
Add scripts or builds steps to run the code locally, Nuke build pipeline to get consistency
Adopt a version strategy and name branches accordingly
Adopt automatic versioning using GitVersion
Adopt logging and exception strategy, e.g. Serilog
Pulumi to automate PR deployments
Improve code
Treat all warnings as errors and fix thhem
Editorconfig / eslint so auto-format works
Configure a personal Rider/R# clean-up profile to auto-format file, project and solution
Roslyn analyzers
Microsoft.CodeAnalysis.BannedApiAnalyzers
StyleCop.Analyzers
CSharpGuidelinesAnalyzer
Roslynator.Analyzers
Meziantou.Analyzer
Enable nullable types per file
Move new code to .NET 6+ or cross-compile
Switch to newer C# versions, possibly using Polysharp
File-scope namespaces
Target-typed news
switch expression
String interpolation instead of string.format
Use Directory.Build.Props to reduce duplication
Improve naming whenever you can
Encapsulate prim itive types and collections in d
Mais conteúdo relacionado
Semelhante a What is the right "unit" in unit testing and why it is not a class?
Test-Driven Development
Test-driven development (TDD) is a software development process that relies on the repetition of a short development cycle of requirements, design, and coding. It promotes writing tests before writing code (test-first design) and helps improve code quality by reducing defects. The TDD cycle involves writing an automated test, running the test and seeing it fail, writing the minimum amount of code to pass the test, and refactoring the code as needed. TDD brings benefits like clarifying requirements, adding executable documentation, and detecting errors early. Acceptance TDD involves automating acceptance tests to define and validate requirements. It helps establish a definition of done and improves team collaboration.
16 things a developer should know about testing
“Do you know a good book about testing software, Wolf?” “Err… actually I don’t. But I know a few things about testing I am happy to share…”
This is how it all started. In this session, Wolf is sharing battle hands-on and battle proven approaches to ensuring that quality is baked into our software from day one.
Learn about the limitations of test driven design, how to test asynchronous behaviour and the merits of bug bashing (just to name a few).
Bio: Wolf is a professionally qualified software engineer with over 20 years of international consulting experience. He works for ThoughtWorks Germany and helps teams delivering working software.
Wolf's primary professional interests are microservices, cloud, continuous delivery, agile enablement and humanitarian software.
TDD Flow: The Mantra in Action
San Francisco Software Craftsmanship Meetup
Test Driven Developers Bay Area Meetup
TDD Flow: The Mantra in Action” is a talk + hands-on about the mantra of TDD and its core patterns. Here are some questions for this talk: What is TDD? How to write a good test that fails? How to write code enough to make the test pass? How to remove duplication? How to refactor code? How to create clean code? Is TDD about testing or design? How small should a test be? Should I only write unit tests? Should I estimate TDD? How to use TDD with other agile methods like Scrum, Kanban or BDD? And finally, how to flow in TDD?
Tdd and-design-draft
The document discusses how test-driven development (TDD) influences class design from the perspective of a practitioner. TDD encourages developers to write easily testable code, which leads to low coupled and highly cohesive classes that follow good object-oriented design principles. Specifically, TDD helps reduce class coupling by making dependencies explicit, focusing on stable abstractions rather than implementations, and avoiding overly complex "god classes." It also improves cohesion by encouraging small specialized classes and composing behaviors through patterns like factories and observers. The practitioner argues that while TDD provides useful feedback on design, it ultimately relies on developers recognizing issues and applying their skills and experience to address them.
Test Driven Development
The document discusses test-driven development (TDD) and design-driven development (DDD). It advocates for writing tests before code using short iterative development cycles. TDD helps produce clean code that fulfills requirements by making developers think about required behavior, providing documentation, and improving quality. Common objections to TDD are addressed, noting that it forces understanding of code and tests, creates reusable modular code, and drives simplicity. Guidelines for effective TDD include writing small focused tests with descriptive intentions that are independent and repeatable.
Extreme Programming: An Introduction to XP Practices
This document provides an overview of the twelve core Extreme Programming (XP) practices introduced by Kent Beck in his 1999 book Extreme Programming Explained. It discusses each practice in 1-2 paragraphs, including planning games, small releases, sustainable pace, whole team, testing, pair programming, coding standards, continuous integration, system metaphor, simple design, refactoring, and collective ownership. The presentation was given by David Hanson, who has experience adopting and integrating XP practices into Agile projects following Scrum and Kanban methodologies.
Introduction to Extreme Programming
This document provides an introduction and overview of eXtreme Programming (XP), an agile software development methodology. It discusses what XP is, its history and origins, core values and principles, practices, and components like the whole XP team. Key aspects of XP covered include pair programming, short development cycles, test-first development, simple design, frequent integration and feedback. The document aims to explain the philosophy and mechanics of the XP methodology.
JavaScript Unit Testing
Presentation developed for JSChannel BLR :: Meetup 8 - Unit testing AngularJS using Jasmine and Karma
Agile principles and practices
Agile * Agile Principles * Agile Practices * Pair Programming * Extreme Programming * SOLID design principles * SDLC * Software Development
After working 10 years in multiple major "from-scratch" development projects, I finally got a chance to work in a truly Agile development project. Here is my take on how to make Agile work for your project.
Pair Programming Talk
This document summarizes the benefits and mechanics of pair programming. It discusses that all production software should be developed by two programmers working jointly, switching pairs frequently. The benefits include continual code review, improved design quality, fewer defects, more rapid solutions, improved communication among team members, and reduced risk. Potential issues that can arise include difficulties with introverts, experts paired with novices, and individuals who refuse to pair program.
The Test Case as Executable Example
The document discusses test cases as executable examples that communicate requirements and system behavior throughout the development cycle. It notes challenges like incomplete or overly large example sets and disconnected examples. The document proposes measuring test case similarity to help understand test suites and group examples. Preliminary evaluation of a technique to rank test cases by similarity showed it could help explain surprises in a test suite. Rethinking test cases as examples and developing languages to write different levels of executable, analyzable, and connected examples is suggested.
Design patterns for Event Sourcing in .NET
Event Sourcing is becoming more mainstream these days, and a lot of conferences have demonstrated the pros and cons of this architecture style from multiple angles. I've done a few of these and publishes a lot of articles on best practices and solutions to common problems. But what nobody did was to show you how to build an event sourced systems in the .NET ecosystem. There are a lot of open-source projects that you can use, so you'll need to find a right mix and your own code to that. So let me show you how I would implement this in .NET with almost 10 years of Event Sourcing experience behind my belt.
My Laws of Test Driven Development (2023)
About 15 years ago, I got inspired by a series of posts on Test Driven Development written by the Jeremy D. Miller. Now, with many years of great and not-so-great experiences practicing Test Driven Development, I thought it is the time to capture my own “laws”. The term "law" is obviously an exaggeration and "principles or heuristics" cover my intend much better. Either way, I want to talk about the scope of testing, using the observable behavior, naming conventions, state-based vs interaction-based testing, the impact of DRY, patterns to build useful test objects and some of the libraries and tools I use. In short, everything I try to follow every day I write, review or maintain code.
Effective unit testing
The document discusses effective unit testing. It covers topics like the value of writing tests, test-driven development, behavior-driven development, test doubles, structuring tests with arrange-act-assert/given-when-then, checking behavior not implementation, test smells, JUnit basics, and parameterized testing. The goal of tests is to validate code behavior, catch mistakes, and shape design. Writing tests also helps learn what the code is intended to do.
Test-Driven Design - ¿Porqué?
The document discusses test-driven development (TDD) and how it can be used to reduce unnecessary complexity, also known as inventory, in software design. TDD involves writing automated tests before code to articulate requirements and ensure only needed code is written. It promotes designing simple, clear code without duplication through principles like You Aren't Gonna Need It and refactoring code in small, reversible steps. Following TDD principles is claimed to reduce inventory created by excess complexity and allow designs to evolve incrementally based on test feedback.
No more Three Tier - A path to a better code for Cloud and Azure
Three Tier is no more a model for Cloud and in general Scalable Web Applications. Scaffolding from SQL Database is, sure, the worst way to do. A road to do this is changing modeling activity, from scaffolded DB model to Command/DTO model, through ViewModel pattern. Command and DTOs are pillars of CQRS model.
Test Driven Development
This document discusses test-driven development (TDD), an approach where unit tests are written before production code to specify functionality. With TDD, developers first write a failing unit test, then produce just enough code to pass that test, and refactor as needed. Key principles are to only write production code to pass tests and not write more of a test than needed to fail initially. TDD is claimed to produce robust code, enable continuous deployment, and allow releasing at any time due to test coverage, though it has a learning curve and time costs. Various testing frameworks and runners that support TDD are also listed.
Software Design for Testability
This document discusses design for testability. It defines testability as having controllability and visibility. Controllability is the ability to apply inputs and place a system in specified states, while visibility is the ability to observe states and outputs. The document outlines why testability is important for improving quality and reducing costs. It describes how to achieve testability through good design practices like abstraction, encapsulation, and avoiding interdependence. Testability features like logging and assertions are also recommended. Development techniques like defensive programming, design by contract, and test-driven development can further enhance testability.
Importance Of Being Driven
The importance to be Driven
There are many buzzwords and acronyms to describe how the software should be designed. TDD (Test Driven), BDD (Behaviour Driven), DDD (Domain Driven) are the most well known. In this speech we'll run thought all these techniques comparing each one of those with TDD and finding what are the common concepts. An exercise will show to the students how different the code will be using different design methodologies as driver.
Human computer interaction research at ibm t
The document describes a study that compared the effectiveness of two approaches to online learning - a custom course assembly approach that dynamically assembled learning objects, and a query engine approach. Subjects using the custom course assembly produced more extensive designs for a given task and performed better based on expert evaluations, even after accounting for differences in experience. The custom course approach may have led to better performance by encouraging focus, providing more relevant content, and creating a more organized learning experience.
Semelhante a What is the right "unit" in unit testing and why it is not a class? (20)
Extreme Programming: An Introduction to XP Practices
Extreme Programming: An Introduction to XP Practices
No more Three Tier - A path to a better code for Cloud and Azure
No more Three Tier - A path to a better code for Cloud and Azure
Mais de Dennis Doomen
Getting a grip on your code dependencies (2023-10)
I'm sure every developer wants to be able to change code with confidence and without fear. Readable and self-explanatory code is one aspect of that. Too much coupling is another major source of problems that prevent you from changing one part of the system without causing side-effects. In this talk, I'd like you to show you common sources of unnecessary coupling and offer you options to help prevent and/or break those. I'll talk about how principles like Don't Repeat Yourself and Dependency Injection can be a double-edge sword, how to detect too unnecessary dependencies and how to use the Dependency Inversion Principle to unravel some of those. And yes, I will also talk about controlling dependencies on the package level.
Challenge
1. How to prevent too much coupling?
2. We are tought to decrease coupling and increase cohesion
3. How do you increase cohesion? By applying DRY!
4. But DRY creates more coupling
5. And too much decoupling results in a forest of abstractions
6. The solution is… find a balance (or "it depends")
On the architecture level
1. Use architecture style that embraces DIP (e.g. Onion, Hexagon, Clean Architecture)
2. Organize your code along functional boundaries -> this will make it easier to break off that boundary for rebuilding/strangler/microservices.
3. Apply DRY within those boundaries only, but allow shared services for complicated capabilities
4. Align your test scope with those internal boundaries…
On the package level
• Classes and interfaces that are almost always used together should be packaged together. Those that don’t meet that criteria don’t have a place in that package
• Packages should not require changes (and thus a new release) for unrelated changes.
• There must be no cycles in the dependency structure
• A package should only depend upon packages that are more stable than it is or abstract packages
On the code level
• Avoid technical folders and organize them by functionalities or capabilities
• Things in adjacent folders usually mean they are separate boundaries
• Use the Tell, Don't Ask principle
• Use the Law of Demeter to detect unnecessary coupling
• Encapsulate primitive types and collections in specific types
• Dependency injection is great, but try to avoid a global container
• It's fine to inject concrete classes inside boundaries
Strategy for legacy code
1. Ensure you have a safety net using characterisation tests
2. Find existing seams and decouple them better
a. Identify modules or functional slices
b. Identify groups of classes that are supposed to be used together and are designed to be reusable
c. Identify interfaces or abstractions in DI registration code and see if they are truly designed for reusability
d. Assume that code in adjacent folders is supposed to be independent
e. Move code from different technical folders that belong together in their own (functionally named) folderPublic
3. Use that to define (and visualize) the target architecture
Tools and practices to help you deal with legacy code
We all love to build greenfield projects, but the reality is that in most jobs you have to deal with a lot of legacy code. This doesn't mean the code is bad. It just means that choices were made that were the right ones at that time, or that the developers were not entire up-to-date with modern development practices. And that's exactly what this talk is about. I enjoy taking such a codebase and gradually introduce architectural seems, add a proper build pipeline, introduce temporary tests and then gradually refactor the codebase to combine more maintainable, testable and reliable. So in this talk, I'd like to unfold my extensive toolbox of practices, principles, tools and mindset to help you improve your legacy code without jeopardizing your business.
Understand production environment
See which vinaries are running in production and what config files are used
Verify the code and the production release are in sync, e.g. DotPeek
Analyze logs to understand what features are used
Try to get it to run on a local environment
Understand code
Generate project diagrams and class hierarchies
Find origin calls and destination of a parameter using Rider
Use navigation options to find inheritors, usages, etc.
Use the namespaces and project names to understand the relation
Have Rider's AI Assistant or ChatGPT explain the code
Track all documentation in a single place
Build C4 diagrams
Find dead code
Reduce the scope of types and members to internal to find more dead code
Detect code inefficiencies and dead code using Rider
Remove commented out code
Build a safety net
If therea are tests, add code coverage reporting using Coverlet and use that to find dark spots
(HTTP API) Characteristics tests using FluentAssertions, Bogus, xUnit. Use AI to generate them. It's fine, you'll delete them later on
Use test containers for .net t lo include the databse
Build a couple of end to end UI tests e.g. using Cypress, Playwright, efc
Improve deployability
Add scripts or builds steps to run the code locally, Nuke build pipeline to get consistency
Adopt a version strategy and name branches accordingly
Adopt automatic versioning using GitVersion
Adopt logging and exception strategy, e.g. Serilog
Pulumi to automate PR deployments
Improve code
Treat all warnings as errors and fix thhem
Editorconfig / eslint so auto-format works
Configure a personal Rider/R# clean-up profile to auto-format file, project and solution
Roslyn analyzers
Microsoft.CodeAnalysis.BannedApiAnalyzers
StyleCop.Analyzers
CSharpGuidelinesAnalyzer
Roslynator.Analyzers
Meziantou.Analyzer
Enable nullable types per file
Move new code to .NET 6+ or cross-compile
Switch to newer C# versions, possibly using Polysharp
File-scope namespaces
Target-typed news
switch expression
String interpolation instead of string.format
Use Directory.Build.Props to reduce duplication
Improve naming whenever you can
Encapsulate prim itive types and collections in d
What you can learn from an open-source project with 250 million downloads
Dennis Doomen presented on FluentAssertions, an open source .NET library for validation of results and state. With over 244 million downloads, it is successful due to its clean code design using test-driven development, extensibility, clear documentation, and support. Doomen discussed tools, practices, and principles from the project, including editorconfig, Roslyn analyzers, approval tests, GitHub Actions, and semantic versioning that can be applied to other projects.
Automate Infrastructure with Pulumi and C#
Who remembers the days were you had to manually setup a physical server somewhere in a 19 inch rack? Nowadays those physical racks have been replaced by virtual machines provided by Google, Microsoft and Amazon. But some people are still provisioning them manually. The more mature organizations will script most of the provisioning using the native CLI or HTTP API provided by the specific cloud platform, but quite often those are maintained separately from the code of the system that is being deployed. Terraform by Hashicorp is another attempt to support infrastructure-as-code by using a declarative syntex to define the desired infrastructure. But then again, Yaml isn't really suited for anything but simple single-file configuration settings. Yaml isn't code and doesn't provide real Intellisense, line-by-line debugging and most importantly, refactoring.
But what if you could use C# and .NET to provision your infrastructure and treat that code as first-class citizens of your codebase, including all the capabilities that you would expect? Well, let me show you how Pulumi for .NET will allow you to evolve your infrastructure code with the rest of the code base without turning it in a big spaghetti of Yaml files.
Slow Event Sourcing (re)projections - Just make them faster!
I don't have to tell anybody how awesome Event Sourcing is as an architecture style. But those that have been using it in production must have experienced the pains of keeping the upgrades fast enough, especially if you use a more traditional relational database like SQL Server. I've once heard somebody say: "If it's slow, make it faster", but rebuilding a big projection is simply a very expensive operations and involves a lot of network traffic between the application and the database servers.
Over the years since we adopted Event Sourcing, we've been experimenting a lot and have implemented various improvements to make those reprojections faster. And we haven't stopped. We're already working on some new ideas lately. So in this session, I'd like to share those techiques, their pros and cons and how we implemented them on a more detailed level.
A lab around the principles and practices for writing maintainable code
Writing maintainable code is not something that is easy to do. Not only is a pretty subjective, a lot of the techniques like Clean Code, SOLID and such can be misinterpreted resulting in unconstructive dogma. I've made it my career's goal to find a good balance between all those different patterns, principles, practices and guidelines.
In this talk, I'd like to share my own ideas on what it takes to write maintainable code. I'll talk about architecture, class design, automated testing and any consequences on your development process. If you care about your code, be there with me.
How to Practice TDD Without Shooting Yourself in the Foot
It’s 2021, so practices like Test Driven Development (TDD) have long found their way into organizations. However, the practices and principles to keep those unit tests maintainable haven’t really changed. Still, Dennis regularly talks to developers that somehow ended up with an incomprehensible unmaintainable set of unit tests that they once believed in, but are now holding them back. So in this session Dennis likes to provide a refresh of those fundamental ideas and talk about why you should practice TDD, revealing intentions, naming conventions, state versus interaction based testing, and how to stay out of the debugger hell with proper mocking and assertion frameworks.
Decomposing the Monolith using modern-day .NET and a touch of microservices
If I have to name a single biggest hype in software architecture land then it would be "microservice". They are supposed to be small and focused, can be deployed independently, can work with any technology and will solve all your monolithical problems. But we all know that silver bullets don't exist, plus technology should never be a goal, but merely a means to an end. Nonetheless, following the path towards real microservices is a great strategy for decomposing a monolith without the deployment complexity of the first. So how do you do that? What technologies does the .NET realm offer for us? In this talk, I'll show you some of the pros and cons of micro-services and its ingredients to leverage modern-day .NET and Event Sourcing to move your monolith into a bright new future.
Event Sourcing from the Trenches (DDD Europe 2020)
Over the years I've spoken many times about what Event Sourcing is and shared many of the good, the bad and the ugly parts of it in blog posts and various talks. However, I've never talked about how to actually build a system based on this architecture style. I keep getting the same questions over and over again. Like when to apply Event Sourcing and at what architectural level. How to deal with transactional boundaries within and outside the domain. How to build projections that are autonomous, reliable and self-supporting. How to deal with upgrades and blue-green deployments. But also on how to handle bugs, design mistakes and crashing projections. Having made a lot of these mistakes myself over these years, it's time to share my current thoughts and opinions about this. Since the .NET space has a pretty rich set of open-source projections to support this, the examples and code will be .NET. But the concepts are universal, so don't let that scare you off.
Practical introduction to DDD, CQRS and Event Sourcing
The document discusses various challenges and solutions related to building applications using an event-driven architecture and event sourcing approach. It addresses issues like handling schema changes, dealing with bugs in projections, improving performance of rebuilding projections, handling archiving of large amounts of historical data, and enhancing events with additional context like original names. Various database technologies and patterns are discussed as solutions, such as using different storage for projections, stream tombstoning, and event modifiers.
How to practice TDD without shooting yourself in the foot
The document discusses test-driven development (TDD) and provides an opinionated definition and guidelines for TDD. It defines TDD as designing class responsibilities, writing an initial unit test, generating code stubs, ensuring the test fails, implementing the code, ensuring the test succeeds, identifying alternative scenarios, and repeating the process twice before refactoring. It also provides examples of code organization for TDD and recommends keeping tests focused on relevant parts of the code and avoiding debugger use. External resources on effective TDD practices are referenced.
Decomposing the Monolith (Riga Dev Days 2019)
A micro-service architecture is a great strategy for decomposing a monolith. In this talk, I’ll show you some of the pros and cons of micro-services and how you can leverage OWIN, .NET, Event Sourcing and the Onion Architecture to gradually move your monolith into a bright new future.
If I have to name a single hype in software architecture land then I would have to mention the micro-service architecture. Micro-services are supposed to be small, have a very focused purpose, can be deployed independently, are completely self-supporting and loosely coupled. Ideally, micro-services are technology agnostic, but hey, we’re in the .NET space, aren’t we? And they are not a goal, but a means to an end. In fact, a micro-service architecture has many benefits and are a great strategy for decomposing a monolith. So how do you build a micro-service? What technologies does the .NET realm offer for us? And what if you don’t want to deploy them independently? In this talk, I’ll show you some of the pros and cons of micro-services and how you can leverage OWIN, .NET, Event Sourcing and the Onion Architecture to gradually move your monolith into a bright new future.
A lab around the principles and practices for writing maintainable code (2019)
Writing maintainable code is not something that is easy to do. Not only is a pretty subjective, a lot of the techniques like Clean Code, SOLID and such can be misinterpreted resulting in unconstructive dogma. I've made it my career's goal to find a good balance between all those different patterns, principles, practices and guidelines. In this talk, I like to share you my own ideas on what it takes to write maintainable code. I'll talk about architecture, class design, automated testing and any consequences on your development process. If you care about your code, be there with me.
Lessons learned from two decades of professional software development
Dennis Doomen discusses key principles for maintainable code, including isolation, testability, being diagnosable, traceability, readability, and discoverability. The goal is code that can be changed confidently by any developer on a team without fear and has a low cognitive load for readers to understand. Dennis Doomen is focused on continuously improving code through these principles.
The Good, The Bad and The Ugly of Event Sourcing
In 2009, I first learned about Event Sourcing and Command Query Responsibility Seggregation (CQRS) at a training Greg Young gave in Utrecht, The Netherlands. I remember being awed by the scalability and architectural simplicity those styles provided. However, I also remembered the technical complexity that comes with it. In 2012, I was in charge of transitioning a CQRS-based system to Event Sourcing. I knew it would be non-trivial, but boy was I in for a surprise. So, over the last four years, I've experienced first-hand how a large group of developers had to deal with the transition. It's a brilliant solution for high-performance or complex business systems, but you need to be aware that this also introduces challenges most people don't tell you about. In this talk, I'd like to share you some of the most powerful benefits of ES, but also show you the flipside of the coin and cover some of the smaller and bigger challenges you'll run into it. Again, I love it and would apply it again without any doubt, but I really want you to understand the trade-offs before you jump on the Event Sourcing train.
Event Sourcing from the Trenches (with examples from .NET)
Over the years I've spoken many times about what Event Sourcing is and shared many of the good, the bad and the ugly parts of it in blog posts and various talks. However, I've never talked about how to actually build a system based on this architecture style. I keep getting the same questions over and over again. Like when to apply Event Sourcing and at what architectural level. How to deal with transactional boundaries within and outside the domain. How to build projections that are autonomous, reliable and self-supporting. How to deal with upgrades and blue-green deployments. But also on how to handle bugs, design mistakes and crashing projections. Having made a lot of these mistakes myself over these years, it's time to share my current thoughts and opinions about this. Since the .NET space has a pretty rich set of open-source projections to support this, the examples and code will be .NET. But the concepts are universal, so don't let that scare you off.
How To Practice TDD Without Shooting Yourself In The Foot
It's 2018, so practices like Test Driven Development (TDD) have long found their way into organizations. However, the practices and principles to keep those unit tests maintainable haven't really changed. Still, I regularly talk to developers that somehow ended up with an incomprehensible unmaintainable set of unit tests that they once believed in, but are now holding them back. So in this session I like to provide a refresh of those fundamental ideas and talk about why you should practice TDD, revealing intentions, naming conventions, state versus interaction based testing, and how to stay out of the debugger hell with proper mocking and assertion frameworks.
Decomposing the monolith into embeddable microservices using OWIN, WebHooks, ...
If I have to name a single hype in software architecture land then I would have to mention the micro-service architecture. Microservices are supposed to be small, have a very focused purpose, can be deployed independently, are completely self-supporting and loosely coupled. Ideally, microservices are technology agnostic, but hey, we're in the .NET space, aren't we? And they are not a goal, but a means to an end. In fact, a microservice architecture has many benefits and are a great strategy for decomposing a monolith. So how do you build a microservice? What technologies does the .NET realm offer for us? And what if you don't want to deploy them independently? In this talk, I'll show you some of the pros and cons of microservices and how you can leverage Event Sourcing, OWIN and .NET to move your monolith into a bright new future.
Strengths and weaknesses of dependency injection
Concepts like the Dependency Inversion Principle, Inversion of Control containers and Dependency Injection libraries are often mixed up, but they are not the same. You shouldn’t use a DI library until you understand the problems your solving, nor is it always the best solution.
Since I’ve felt this pain many times myself, I’d like to use this session to create some clarity. First, I’ll demonstrate the reason why people typically use libraries like Unity and Autofac in their code bases. Then I’ll show you that those same people often use the Dependency Inversion Principle in the wrong way (and need to revert to mocking libraries to compensate). Then I’ll show you how to apply the principles properly by carefully designing the seams in your architecture. And finally, I’ll show you how an advanced library can connect the dots in a very elegant way.
Build Libraries That People Love To use
Frameworks are supposed to help you build things more quicker and hide a lot of complexity around cross-cutting and infrastructural concerns. They are supposed to make it easier for inexperienced developers to join a running projection. But frameworks also introduce a lot of magic, and that magic is going to backfire at some point. At least, that's my experience. And when it backfires, your code is so entangled with that framework, that you can't get rid of it anymore.
So, instead of building and using frameworks, build and use libraries. That's easier said then done, and I'll can talk about many great and not so great examples. So let me share some of the practices I use to build composable libraries myself. I'll talk about principles of package design and scoping, keeping your NuGet package dependencies in check, and how to use layered APIs to increase usability without hiding the magic.
Mais de Dennis Doomen (20)
Getting a grip on your code dependencies (2023-10)
Getting a grip on your code dependencies (2023-10)
Tools and practices to help you deal with legacy code
Tools and practices to help you deal with legacy code
What you can learn from an open-source project with 250 million downloads
What you can learn from an open-source project with 250 million downloads
Slow Event Sourcing (re)projections - Just make them faster!
Slow Event Sourcing (re)projections - Just make them faster!
A lab around the principles and practices for writing maintainable code
A lab around the principles and practices for writing maintainable code
How to Practice TDD Without Shooting Yourself in the Foot
How to Practice TDD Without Shooting Yourself in the Foot
Decomposing the Monolith using modern-day .NET and a touch of microservices
Decomposing the Monolith using modern-day .NET and a touch of microservices
Event Sourcing from the Trenches (DDD Europe 2020)
Event Sourcing from the Trenches (DDD Europe 2020)
Practical introduction to DDD, CQRS and Event Sourcing
Practical introduction to DDD, CQRS and Event Sourcing
How to practice TDD without shooting yourself in the foot
How to practice TDD without shooting yourself in the foot
A lab around the principles and practices for writing maintainable code (2019)
A lab around the principles and practices for writing maintainable code (2019)
Lessons learned from two decades of professional software development
Lessons learned from two decades of professional software development
Event Sourcing from the Trenches (with examples from .NET)
Event Sourcing from the Trenches (with examples from .NET)
How To Practice TDD Without Shooting Yourself In The Foot
How To Practice TDD Without Shooting Yourself In The Foot
Decomposing the monolith into embeddable microservices using OWIN, WebHooks, ...
Decomposing the monolith into embeddable microservices using OWIN, WebHooks, ...
Último
Ocean lotus Threat actors project by John Sitima 2024 (1).pptx
Ocean Lotus cyber threat actors represent a sophisticated, persistent, and politically motivated group that poses a significant risk to organizations and individuals in the Southeast Asian region. Their continuous evolution and adaptability underscore the need for robust cybersecurity measures and international cooperation to identify and mitigate the threats posed by such advanced persistent threat groups.
TrustArc Webinar - 2024 Global Privacy Survey
How does your privacy program stack up against your peers? What challenges are privacy teams tackling and prioritizing in 2024?
In the fifth annual Global Privacy Benchmarks Survey, we asked over 1,800 global privacy professionals and business executives to share their perspectives on the current state of privacy inside and outside of their organizations. This year’s report focused on emerging areas of importance for privacy and compliance professionals, including considerations and implications of Artificial Intelligence (AI) technologies, building brand trust, and different approaches for achieving higher privacy competence scores.
See how organizational priorities and strategic approaches to data security and privacy are evolving around the globe.
This webinar will review:
- The top 10 privacy insights from the fifth annual Global Privacy Benchmarks Survey
- The top challenges for privacy leaders, practitioners, and organizations in 2024
- Key themes to consider in developing and maintaining your privacy program
Introduction of Cybersecurity with OSS at Code Europe 2024
I develop the Ruby programming language, RubyGems, and Bundler, which are package managers for Ruby. Today, I will introduce how to enhance the security of your application using open-source software (OSS) examples from Ruby and RubyGems.
The first topic is CVE (Common Vulnerabilities and Exposures). I have published CVEs many times. But what exactly is a CVE? I'll provide a basic understanding of CVEs and explain how to detect and handle vulnerabilities in OSS.
Next, let's discuss package managers. Package managers play a critical role in the OSS ecosystem. I'll explain how to manage library dependencies in your application.
I'll share insights into how the Ruby and RubyGems core team works to keep our ecosystem safe. By the end of this talk, you'll have a better understanding of how to safeguard your code.
Energy Efficient Video Encoding for Cloud and Edge Computing Instances
Energy Efficient Video Encoding for Cloud and Edge Computing Instances
“Building and Scaling AI Applications with the Nx AI Manager,” a Presentation...
“Building and Scaling AI Applications with the Nx AI Manager,” a Presentation...Edge AI and Vision Alliance
For the full video of this presentation, please visit: https://www.edge-ai-vision.com/2024/06/building-and-scaling-ai-applications-with-the-nx-ai-manager-a-presentation-from-network-optix/
Robin van Emden, Senior Director of Data Science at Network Optix, presents the “Building and Scaling AI Applications with the Nx AI Manager,” tutorial at the May 2024 Embedded Vision Summit.
In this presentation, van Emden covers the basics of scaling edge AI solutions using the Nx tool kit. He emphasizes the process of developing AI models and deploying them globally. He also showcases the conversion of AI models and the creation of effective edge AI pipelines, with a focus on pre-processing, model conversion, selecting the appropriate inference engine for the target hardware and post-processing.
van Emden shows how Nx can simplify the developer’s life and facilitate a rapid transition from concept to production-ready applications.He provides valuable insights into developing scalable and efficient edge AI solutions, with a strong focus on practical implementation.みなさんこんにちはこれ何文字まで入るの？40文字以下不可とか本当に意味わからないけどこれ限界文字数書いてないからマジでやばい文字数いけるんじゃないの？えこ...
ここ3000字までしか入らないけどタイトルの方がたくさん文字入ると思います。
AI 101: An Introduction to the Basics and Impact of Artificial Intelligence
Imagine a world where machines not only perform tasks but also learn, adapt, and make decisions. This is the promise of Artificial Intelligence (AI), a technology that's not just enhancing our lives but revolutionizing entire industries.
Presentation of the OECD Artificial Intelligence Review of Germany
Consult the full report at https://www.oecd.org/digital/oecd-artificial-intelligence-review-of-germany-609808d6-en.htm
Driving Business Innovation: Latest Generative AI Advancements & Success Story
Are you ready to revolutionize how you handle data? Join us for a webinar where we’ll bring you up to speed with the latest advancements in Generative AI technology and discover how leveraging FME with tools from giants like Google Gemini, Amazon, and Microsoft OpenAI can supercharge your workflow efficiency.
During the hour, we’ll take you through:
Guest Speaker Segment with Hannah Barrington: Dive into the world of dynamic real estate marketing with Hannah, the Marketing Manager at Workspace Group. Hear firsthand how their team generates engaging descriptions for thousands of office units by integrating diverse data sources—from PDF floorplans to web pages—using FME transformers, like OpenAIVisionConnector and AnthropicVisionConnector. This use case will show you how GenAI can streamline content creation for marketing across the board.
Ollama Use Case: Learn how Scenario Specialist Dmitri Bagh has utilized Ollama within FME to input data, create custom models, and enhance security protocols. This segment will include demos to illustrate the full capabilities of FME in AI-driven processes.
Custom AI Models: Discover how to leverage FME to build personalized AI models using your data. Whether it’s populating a model with local data for added security or integrating public AI tools, find out how FME facilitates a versatile and secure approach to AI.
We’ll wrap up with a live Q&A session where you can engage with our experts on your specific use cases, and learn more about optimizing your data workflows with AI.
This webinar is ideal for professionals seeking to harness the power of AI within their data management systems while ensuring high levels of customization and security. Whether you're a novice or an expert, gain actionable insights and strategies to elevate your data processes. Join us to see how FME and AI can revolutionize how you work with data!
UiPath Test Automation using UiPath Test Suite series, part 6
Welcome to UiPath Test Automation using UiPath Test Suite series part 6. In this session, we will cover Test Automation with generative AI and Open AI.
UiPath Test Automation with generative AI and Open AI webinar offers an in-depth exploration of leveraging cutting-edge technologies for test automation within the UiPath platform. Attendees will delve into the integration of generative AI, a test automation solution, with Open AI advanced natural language processing capabilities.
Throughout the session, participants will discover how this synergy empowers testers to automate repetitive tasks, enhance testing accuracy, and expedite the software testing life cycle. Topics covered include the seamless integration process, practical use cases, and the benefits of harnessing AI-driven automation for UiPath testing initiatives. By attending this webinar, testers, and automation professionals can gain valuable insights into harnessing the power of AI to optimize their test automation workflows within the UiPath ecosystem, ultimately driving efficiency and quality in software development processes.
What will you get from this session?
1. Insights into integrating generative AI.
2. Understanding how this integration enhances test automation within the UiPath platform
3. Practical demonstrations
4. Exploration of real-world use cases illustrating the benefits of AI-driven test automation for UiPath
Topics covered:
What is generative AI
Test Automation with generative AI and Open AI.
UiPath integration with generative AI
Speaker:
Deepak Rai, Automation Practice Lead, Boundaryless Group and UiPath MVP
OpenID AuthZEN Interop Read Out - Authorization
During Identiverse 2024 and EIC 2024, members of the OpenID AuthZEN WG got together and demoed their authorization endpoints conforming to the AuthZEN API
Programming Foundation Models with DSPy - Meetup Slides
Prompting language models is hard, while programming language models is easy. In this talk, I will discuss the state-of-the-art framework DSPy for programming foundation models with its powerful optimizers and runtime constraint system.
HCL Notes und Domino Lizenzkostenreduzierung in der Welt von DLAU
Webinar Recording: https://www.panagenda.com/webinars/hcl-notes-und-domino-lizenzkostenreduzierung-in-der-welt-von-dlau/
DLAU und die Lizenzen nach dem CCB- und CCX-Modell sind für viele in der HCL-Community seit letztem Jahr ein heißes Thema. Als Notes- oder Domino-Kunde haben Sie vielleicht mit unerwartet hohen Benutzerzahlen und Lizenzgebühren zu kämpfen. Sie fragen sich vielleicht, wie diese neue Art der Lizenzierung funktioniert und welchen Nutzen sie Ihnen bringt. Vor allem wollen Sie sicherlich Ihr Budget einhalten und Kosten sparen, wo immer möglich. Das verstehen wir und wir möchten Ihnen dabei helfen!
Wir erklären Ihnen, wie Sie häufige Konfigurationsprobleme lösen können, die dazu führen können, dass mehr Benutzer gezählt werden als nötig, und wie Sie überflüssige oder ungenutzte Konten identifizieren und entfernen können, um Geld zu sparen. Es gibt auch einige Ansätze, die zu unnötigen Ausgaben führen können, z. B. wenn ein Personendokument anstelle eines Mail-Ins für geteilte Mailboxen verwendet wird. Wir zeigen Ihnen solche Fälle und deren Lösungen. Und natürlich erklären wir Ihnen das neue Lizenzmodell.
Nehmen Sie an diesem Webinar teil, bei dem HCL-Ambassador Marc Thomas und Gastredner Franz Walder Ihnen diese neue Welt näherbringen. Es vermittelt Ihnen die Tools und das Know-how, um den Überblick zu bewahren. Sie werden in der Lage sein, Ihre Kosten durch eine optimierte Domino-Konfiguration zu reduzieren und auch in Zukunft gering zu halten.
Diese Themen werden behandelt
- Reduzierung der Lizenzkosten durch Auffinden und Beheben von Fehlkonfigurationen und überflüssigen Konten
- Wie funktionieren CCB- und CCX-Lizenzen wirklich?
- Verstehen des DLAU-Tools und wie man es am besten nutzt
- Tipps für häufige Problembereiche, wie z. B. Team-Postfächer, Funktions-/Testbenutzer usw.
- Praxisbeispiele und Best Practices zum sofortigen Umsetzen
5th LF Energy Power Grid Model Meet-up Slides
5th Power Grid Model Meet-up
It is with great pleasure that we extend to you an invitation to the 5th Power Grid Model Meet-up, scheduled for 6th June 2024. This event will adopt a hybrid format, allowing participants to join us either through an online Mircosoft Teams session or in person at TU/e located at Den Dolech 2, Eindhoven, Netherlands. The meet-up will be hosted by Eindhoven University of Technology (TU/e), a research university specializing in engineering science & technology.
Power Grid Model
The global energy transition is placing new and unprecedented demands on Distribution System Operators (DSOs). Alongside upgrades to grid capacity, processes such as digitization, capacity optimization, and congestion management are becoming vital for delivering reliable services.
Power Grid Model is an open source project from Linux Foundation Energy and provides a calculation engine that is increasingly essential for DSOs. It offers a standards-based foundation enabling real-time power systems analysis, simulations of electrical power grids, and sophisticated what-if analysis. In addition, it enables in-depth studies and analysis of the electrical power grid’s behavior and performance. This comprehensive model incorporates essential factors such as power generation capacity, electrical losses, voltage levels, power flows, and system stability.
Power Grid Model is currently being applied in a wide variety of use cases, including grid planning, expansion, reliability, and congestion studies. It can also help in analyzing the impact of renewable energy integration, assessing the effects of disturbances or faults, and developing strategies for grid control and optimization.
What to expect
For the upcoming meetup we are organizing, we have an exciting lineup of activities planned:
-Insightful presentations covering two practical applications of the Power Grid Model.
-An update on the latest advancements in Power Grid -Model technology during the first and second quarters of 2024.
-An interactive brainstorming session to discuss and propose new feature requests.
-An opportunity to connect with fellow Power Grid Model enthusiasts and users.
National Security Agency - NSA mobile device best practices
Threats to mobile devices are more prevalent and increasing in scope and complexity. Users of mobile devices desire to take full advantage of the features
available on those devices, but many of the features provide convenience and capability but sacrifice security. This best practices guide outlines steps the users can take to better protect personal devices and information.
GraphRAG for Life Science to increase LLM accuracy
GraphRAG for life science domain, where you retriever information from biomedical knowledge graphs using LLMs to increase the accuracy and performance of generated answers
Choosing The Best AWS Service For Your Website + API.pptx
Have you ever been confused by the myriad of choices offered by AWS for hosting a website or an API?
Lambda, Elastic Beanstalk, Lightsail, Amplify, S3 (and more!) can each host websites + APIs. But which one should we choose?
Which one is cheapest? Which one is fastest? Which one will scale to meet our needs?
Join me in this session as we dive into each AWS hosting service to determine which one is best for your scenario and explain why!
Último (20)
Ocean lotus Threat actors project by John Sitima 2024 (1).pptx
Ocean lotus Threat actors project by John Sitima 2024 (1).pptx
Introduction of Cybersecurity with OSS at Code Europe 2024
Introduction of Cybersecurity with OSS at Code Europe 2024
Energy Efficient Video Encoding for Cloud and Edge Computing Instances
Energy Efficient Video Encoding for Cloud and Edge Computing Instances
“Building and Scaling AI Applications with the Nx AI Manager,” a Presentation...
“Building and Scaling AI Applications with the Nx AI Manager,” a Presentation...
みなさんこんにちはこれ何文字まで入るの？40文字以下不可とか本当に意味わからないけどこれ限界文字数書いてないからマジでやばい文字数いけるんじゃないの？えこ...
みなさんこんにちはこれ何文字まで入るの？40文字以下不可とか本当に意味わからないけどこれ限界文字数書いてないからマジでやばい文字数いけるんじゃないの？えこ...
AI 101: An Introduction to the Basics and Impact of Artificial Intelligence
AI 101: An Introduction to the Basics and Impact of Artificial Intelligence
Presentation of the OECD Artificial Intelligence Review of Germany
Presentation of the OECD Artificial Intelligence Review of Germany
Driving Business Innovation: Latest Generative AI Advancements & Success Story
Driving Business Innovation: Latest Generative AI Advancements & Success Story
UiPath Test Automation using UiPath Test Suite series, part 6
UiPath Test Automation using UiPath Test Suite series, part 6
Programming Foundation Models with DSPy - Meetup Slides
Programming Foundation Models with DSPy - Meetup Slides
HCL Notes und Domino Lizenzkostenreduzierung in der Welt von DLAU
HCL Notes und Domino Lizenzkostenreduzierung in der Welt von DLAU
National Security Agency - NSA mobile device best practices
National Security Agency - NSA mobile device best practices
Nordic Marketo Engage User Group_June 13_ 2024.pptx
Nordic Marketo Engage User Group_June 13_ 2024.pptx
GraphRAG for Life Science to increase LLM accuracy
GraphRAG for Life Science to increase LLM accuracy
Choosing The Best AWS Service For Your Website + API.pptx
Choosing The Best AWS Service For Your Website + API.pptx
What is the right "unit" in unit testing and why it is not a class?
- 1. …and why is it not a class What’s the “unit” in unit testing Dennis Doomen
- 2. About Me Hands-on architect in the .NET space with 25 years of experience on an everlasting quest for knowledge to build the right software the right way at the right time
- 4. Why is this important?
- 5. Test Driven Development in reality Design class responsibilities Write first unit test Generate stubs Fail for the right reason Implement real deal Ensure test succeeds Identify alternative scenarios Repeat twice Refactor
- 6. Heuristics to find the right scope
- 7. Designed for reusability? Then tested separately
- 8. Is it an implementation detail? Then don’t test it directly
- 9. Is the test really testing the real surface area?
- 10. Does refactoring require rewriting the tests?
- 11. Things in adjacent folders usually mean they are separate
- 12. Returning mocks from mocks is often a sign of a scope issue
- 18. Tips to improve testability
- 19. It’s fine to include the database in tests
- 20. It’s fine to test smaller when it adds value
- 21. Don't bother arguing about “unit” vs “integration”
- 23. Apply DRY within those boundaries
- 24. Mock the dependencies outside of the scope
- 25. A less trivial example
- 26. Command Handlers Commands Domain Model Event Store Events App Read Data RavenDB Projectors Events HTTP API Projections Events
- 27. Test Fixture In-Memory Event Store Read Data RavenDB Projectors Events HTTP API Projections Unit Test HTTP request Test Data
- 28. Q&A …ask at fluentassertions.slack.com …ping me at @ddoomen …email me at dennis.doomen@avivasolutions.nl