Presentation at Agile 2012
Experience and research shows that developers spend as much as 70% of their time reading and understanding code. In this workshop you will learn how the rules of Simple Design help to reduce this percentage so you spend more time creating valuable code. This will be a highly collaborative workshop where you share your insights and learn from others. You’ll get to the heart of Simple Design by reviewing code - both beautiful and ugly. You’ll get to practice by improving the readability and understandability of real code. You’ll leave this workshop ready to apply Simple Design to improve your own code.
Rule 1: Follow a consistent coding standard
Rule 2: Name things properly, long variable and function names are allowed
Rule 3: Be expressive, write code as you speak and be optimally verbose
Rule 4: Max indent per method should be 2, in case of exceptions 3
Rule 5: Avoid creating god object and long methods
Rule 6: Keep the method in one place, inject the class and call it, DRY
Rule 7: Avoid in-line comments (comment with code), put comments in the method doc
.NET Coding Standards For The Real World (2012)David McCarter
Revamped for 2012, this session will guide any level of programmer to greater productivity by providing the information needed to write consistent, maintainable code. Learn about project setup, assembly layout, code style, defensive programming and much, much more. Code tips are included to help you write better, error free applications. Lots of code examples in C# and VB.NET. This session is based off my latest book, David McCarter's .NET Coding Standards.
Rule 1: Follow a consistent coding standard
Rule 2: Name things properly, long variable and function names are allowed
Rule 3: Be expressive, write code as you speak and be optimally verbose
Rule 4: Max indent per method should be 2, in case of exceptions 3
Rule 5: Avoid creating god object and long methods
Rule 6: Keep the method in one place, inject the class and call it, DRY
Rule 7: Avoid in-line comments (comment with code), put comments in the method doc
.NET Coding Standards For The Real World (2012)David McCarter
Revamped for 2012, this session will guide any level of programmer to greater productivity by providing the information needed to write consistent, maintainable code. Learn about project setup, assembly layout, code style, defensive programming and much, much more. Code tips are included to help you write better, error free applications. Lots of code examples in C# and VB.NET. This session is based off my latest book, David McCarter's .NET Coding Standards.
Talk @ RubyConfIndia 2012. Ruby is a pure object oriented and really a beautiful language to learn and practice.
But most of us do not bother to know or care about what happens behind the scene when we write some ruby code. Say creating a simple Array, Hash, class, module or any object. How does this map internally to C code ?
Ruby interpreter is implemented in C and I will talk about the Interpreter API that we as ruby developers
should be aware of. The main purpose of the presentation is to understand the efforts and complexity behind
the simplicity offered. I would also like to touch upon the difference in implementation of some core data structures
in different ruby versions. Having known a part of C language implementation behind Ruby, I would also like to throw some light upon when and why would we need to write some ruby extensions in C.
Dynamic programming languages are historically slow, right? So we could never use Python or Ruby for any kind of heavy-duty calculations, for example. Before Microsoft introduced the Dynamic Language Runtime (DLR), that may have been the obvious conclusion. However, in this highly interactive discussion, we're going to measure the performance of several computationally intensive operations in a static programming language and in a dynamic one. Thanks to the brilliance of the DLR team at Microsoft, you'll be surprised at the kinds of optimizations you get using those wonderfully expressive dynamic languages, making them truly fly on the .NET platform. You'll also learn some handy language integration tricks along the way. If you've ever thought that a dynamic programming language would help to solve a business problem in an elegant way but worried about the performance of the system, this presentation is for you.
Insights demonstrate that more than 1.5 billion applications and recreations are downloaded each month. Think about this, each 100-200 individuals have an inclination and an application is right away worked for that. Presently it is reasonable why the requirement for Android application advancement is expanding so quickly Android training in Nagpur enables the understudies to learn Android programming and Android application improvement.
Talk @ RubyConfIndia 2012. Ruby is a pure object oriented and really a beautiful language to learn and practice.
But most of us do not bother to know or care about what happens behind the scene when we write some ruby code. Say creating a simple Array, Hash, class, module or any object. How does this map internally to C code ?
Ruby interpreter is implemented in C and I will talk about the Interpreter API that we as ruby developers
should be aware of. The main purpose of the presentation is to understand the efforts and complexity behind
the simplicity offered. I would also like to touch upon the difference in implementation of some core data structures
in different ruby versions. Having known a part of C language implementation behind Ruby, I would also like to throw some light upon when and why would we need to write some ruby extensions in C.
Dynamic programming languages are historically slow, right? So we could never use Python or Ruby for any kind of heavy-duty calculations, for example. Before Microsoft introduced the Dynamic Language Runtime (DLR), that may have been the obvious conclusion. However, in this highly interactive discussion, we're going to measure the performance of several computationally intensive operations in a static programming language and in a dynamic one. Thanks to the brilliance of the DLR team at Microsoft, you'll be surprised at the kinds of optimizations you get using those wonderfully expressive dynamic languages, making them truly fly on the .NET platform. You'll also learn some handy language integration tricks along the way. If you've ever thought that a dynamic programming language would help to solve a business problem in an elegant way but worried about the performance of the system, this presentation is for you.
Insights demonstrate that more than 1.5 billion applications and recreations are downloaded each month. Think about this, each 100-200 individuals have an inclination and an application is right away worked for that. Presently it is reasonable why the requirement for Android application advancement is expanding so quickly Android training in Nagpur enables the understudies to learn Android programming and Android application improvement.
Android is a product stage created by Google they move in the direction of making applications which can be effectively got to on handsets or cell phones, cell phones additionally are enhancing their highlights step by step to stay aware of the applications being created. Android classes in Pune train their understudies how to make new applications utilizing Android and also creating Android as a programming.
Evolving a Clean, Pragmatic Architecture at JBCNConf 2019Victor Rentea
Are you in a mood for a brainstorm? Join this critical review of the major decisions taken in a typical enterprise application architecture and learn to balance pragmatism with your design goals. Find out how to do just-in-time design to keep as much use-cases as simple as possible. The core purpose of this presentation is to learn to strike a **balance between pragmatism and maintainability** in your design. Without continuous refactoring, a simple design will inevitably degenerate into a Big Ball of Mud, under the assault of the new features and bugfixes. On the other hand, very highly-factored code can burden the take-off of the development and end up freezing the mindset in some rigid 'a-priori' design. The end goal of this talk is to challenge you to rethink critically the architecture of your own systems, and seek ways to simplify it to match your actual needs, with a pragmatic mindset. "Architecture is the art of postponing decisions", said Uncle Bob. This talk takes this idea further and explains an optimal mindset about designing enterprise applications: Evolving (Continuously Refactoring) a Pragmatic (Simple), Clean (aka Onion) Architecture, aiming to provide Developer Safety™️ and Comfort™️. It’s the philosophy that Victor distilled over the past 5 years, designing and implementing 9 applications as IBM Lead Architect, and delivering trainings and advises to many other companies. You’ll learn how to break data into pieces (Fit Entities, Value Objects, Data Transfer Objects), how to keep the logic simple (Facades, Domain Services, logic extraction patterns, Mappers, AOP), layering to enforce boundaries (keeping DTOs out of your logic, Dependency Inversion Principle), and many more, all in a dynamic, interactive and extremely entertaining session.
Awareness of design smells - indicators of common design problems - helps developers or software engineers understand mistakes made while designing and apply design principles for creating high-quality designs. This workshop provides insights gained from performing refactoring in real-world projects to improve refactoring and reduce the time and costs of managing software projects. The workshop also presents insightful anecdotes and case studies drawn from the trenches of real-world projects. By attending this workshop, you will know pragmatic techniques for refactoring design smells to manage technical debt and to create and maintain high-quality software in practice.
Contents overview:
* Why care about design principles, design quality, or design smells?
* Refactoring as the primary means for repaying technical debt
* Smells that violate abstraction, encapsulation, modularisation, or hierarchy
* Tools and techniques for refactoring
Refactoring for Software Design Smells - Tech Talk Ganesh Samarthyam
Awareness of design smells - indicators of common design problems - helps developers or software engineers understand mistakes made while designing and apply design principles for creating high-quality designs. This workshop provides insights gained from performing refactoring in real-world projects to improve refactoring and reduce the time and costs of managing software projects. The workshop also presents insightful anecdotes and case studies drawn from the trenches of real-world projects. By attending this workshop, you will know pragmatic techniques for refactoring design smells to manage technical debt and to create and maintain high-quality software in practice.
Contents overview:
* Why care about design principles, design quality, or design smells?
* Refactoring as the primary means for repaying technical debt
* Smells that violate abstraction, encapsulation, modularisation, or hierarchy
* Tools and techniques for refactoring
Building Services With gRPC, Docker and GoMartin Kess
gRPC is an open-source framework for building language agnostic services and clients. This hands-on session will cover techniques for building, testing and monitoring gRPC services using Docker and Go. During this session you will build a simple gRPC service and client, as well as an HTTP reverse-proxy to allow your service to also receive HTTP traffic.
Presentación para la charla sobre el libro de Robert C. Martin, Clean Code.
Esta presentación la impartí en CyLicon Valley, aquí tenéis el video con el audio de la charla => https://www.youtube.com/watch?v=1Fss1jBfc3g
Technical debt is a systemic problem - not a personal failingDeclan Whelan
This is a presentation Chris Chapman I delivered at the Toronto Agile Conference 2017. We take a 'systems thinking' view of technical debt.
The premise is that mounting technical debt is a not a problem ... it's a system problem. We depict system problems using causal loop diagrams and propose steps, via balancing loops, to shift the system to a healthier state.
We use the term 'technical health' to describe this systems view of technical debt.
From Technical Debt to Technical HealthDeclan Whelan
Everyone agrees that technical debt is a burden on software innovation that we would rather avoid, and certainly clean up whenever possible. However, in most organizations, people don't prevent technical debt nearly as much as they should, and they don't ever get the time to clean it up. Why, then, if there are clear incentives to deal with technical debt, is it a rampant problem?
In this session, we will focus on how to deal with technical debt on several levels, including the individual developer, the team, the software value stream, and the larger organization. While technical debt may manifest itself in a developer's IDE, the problem starts long before the developer decides to copy and paste some code, or creates an overly-complex and under-documented class. The pressures on teams and individuals to take on more debt than they should come from many sources. Therefore, the solutions to the technical debt problem must extend beyond the team.
Many organizations adopting Agile fail to bring about lasting change. This is often because Agile is seen as a developer team "methodology". Effective Agile adoption depends on aligning the adoption strategy with the value stream across the organization. In this talk, Declan will introduce the Agile Fluency model as a mechanism for targeting an Agile adoption to the realities of your organization. Along the way we will talk about aligning your organizational structure with your organization's purpose and the importance of managing technical debt.
This is a rough presentation from my notes for the SDEC 2015 conference.
The basic premise is that Big Balls of Mud result from rampant technical debt. And the cost of technical debt is large.
I believe that the forces driving us to repeatedly build big balls of mud are strong. And while technical craftsmanship is necessary to address it, by itself it is insufficient. I explore some root causes through the use of system archetypes.
Finally, I suggest some remedial steps for dealing with technical debt based on the quadrant from Martin Fowler.
Thanks for checking this out!
Einstein said "We cannot solve our problems with the same thinking we used when we created them" yet many organizations that want to adopt Agile end up using existing organizational structures to make it happen. That is, they create a centralized team to roll Agile out, define metrics, create a dashboard, communication and training plan and finally a Sharepoint site to push the change outwards. The outcome ends up being another failed Agile transformation story because people either resisted change or they failed to change their organizational culture. This isn't an 'Agile' problem, it's a structure problem. The real issue is that organizational structures are designed to serve the internal purposes of the organization, not their customers or the value they create for their customers. In this session we'll explore why 'being Agile' only gets you so far.
Domain Driven Design and Hexagonal Architecture with RailsDeclan Whelan
You know that Domain Driven Design, Hexagonal Architecture, and the Single Responsibility Principle are important but it’s hard to know how to best apply them to Rails applications. Following the path of least-resistance will get you in trouble. In this session you will learn a way out of the “fat model, skinny controller” hell. You will leave with a roadmap to guide your design based on concepts from Domain Driven Design and Hexagonal Architecture.
A powerful phrase we learn as agile coaches is to “*release the outcome!*”. In other words, coaching is most effective when we distance ourselves from the final outcomes. Instead, we should focus on helping those we are coaching, visualize and achieve the outcomes that are important to them.
But many of us are Scrum Masters, managers, executives or in similar positions where we have a vested interest in outcomes. So, how do we effectively coach when we have such a bias?
In this session you will learn and practice a powerful conversation tool that allows you to maintain a coaching stance when outcomes are personally important to you. This will allow you to build trust and align others around shared outcomes resulting in win-win situations. Many people also find this conversational tool to be very useful in their personal lives.
This slide deck is about nurturing a learning culture with an agile team. The main ideas are that effective learning is what enables teams to respond to change and deliver exception value. The presentation highlights some key
Presentation on building a learning culture melding principles & practices from systems thinking, Satir, Shu Ha Ri. Ends with a learning map you can use to help build a learning culture on your agile team.
Agile Testing: The Role Of The Agile TesterDeclan Whelan
This presentation provides an overview of the role of testers on agile teams.
In essence, the differences between testers and developers should blur so that focus is the whole team completing stories and delivering value.
Testers can add more value on agile teams by contributing earlier and moving from defect detection to defect prevention.
Welcome to the Program Your Destiny course. In this course, we will be learning the technology of personal transformation, neuroassociative conditioning (NAC) as pioneered by Tony Robbins. NAC is used to deprogram negative neuroassociations that are causing approach avoidance and instead reprogram yourself with positive neuroassociations that lead to being approach automatic. In doing so, you change your destiny, moving towards unlocking the hypersocial self within, the true self free from fear and operating from a place of personal power and love.
10. Simple Design
1. All tests must pass
2. No code is duplicated
3. Code is self-explanatory
4. No superfluous parts exist
11.
12. Simple Design
1. All tests must pass
2. No code is duplicated
3. Code is self-explanatory
4. No superfluous parts exist
13. Simple Design
1. Passes its tests
2. No code is duplicated
3. Code is self-explanatory
4. No superfluous parts exist
14. Simple Design
1. Passes its tests
2. Minimizes duplication
3. Code is self-explanatory
4. No superfluous parts exist
15. Simple Design
1. Passes its tests
2. Minimizes duplication
3. Maximizes clarity
4. No superfluous parts exist
16. Simple Design
1. Passes its tests
2. Minimizes duplication
3. Maximizes clarity
4. Has fewer elements
17. Simple Design
1. Passes its tests (given TDD)
2. Minimizes duplication
3. Maximizes clarity
4. Has fewer elements
18. Simple Design
1. Passes its tests (given TDD)
2. Minimizes duplication
3. Maximizes clarity (fix names)
4. Has fewer elements
19. Simple Design
1. Passes its tests (given TDD)
2. Minimizes duplication
3. Maximizes clarity (fix names)
4. Has fewer elements
20. That leaves me with two key elements
of simple design: remove duplication and
fix bad names.
When I remove duplication, I tend to see
an appropriate structure emerge, and when
I fix bad names, I tend to see responsibilities
slide into appropriate parts of the design.
J. B. Rainsberger
44. CComBstr sVal $.getJSON() int result
Rx rx applyMeasureConstraintToEnableSortingByMeasure() float hp
applyPhq9DateRangeConstraint() public void run() Date genymdhms
m_name Label label IShapeFactory
Customer int i RollOverPerformanceIndicatorsToNextMonthTask
CustomerManager LPSTR lpCmdLine int daysSinceModification
boolean fNewPage UpdatePerfIndValueDecCountCmd DepressionSelfManagementCalculator
Tutorial02
PerfIndValueDecCountForMatchingIvpCmd PulseRenderer IndexCardPageLayout sut
45. CComBstr sVal $.getJSON() int result
Rx rx applyMeasureConstraintToEnableSortingByMeasure() float hp
applyPhq9DateRangeConstraint() public void run() Date genymdhms
m_name Label label IShapeFactory
Customer int i RollOverPerformanceIndicatorsToNextMonthTask
CustomerManager LPSTR lpCmdLine int daysSinceModification
boolean fNewPage UpdatePerfIndValueDecCountCmd DepressionSelfManagementCalculator
Tutorial02
PerfIndValueDecCountForMatchingIvpCmd PulseRenderer IndexCardPageLayout sut
46. Find a partner and each of you:
1. select a name you thought was good
2. explain why to your partner
3. select a name you thought was bad
4. explain why to your partner
CComBstr sVal $.getJSON() int result
Rx rx applyMeasureConstraintToEnableSortingByMeasure() float hp
applyPhq9DateRangeConstraint() public void run() Date genymdhms
m_name Label label IShapeFactory
Customer int i RollOverPerformanceIndicatorsToNextMonthTask
CustomerManager LPSTR lpCmdLine int daysSinceModification
boolean fNewPage UpdatePerfIndValueDecCountCmd DepressionSelfManagementCalculator
PerfIndValueDecCountForMatchingIvpCmd PulseRenderer IndexCardPageLayout sut
48. Choosing Good Names
Use the telephone test for readability.
If someone could understand your
code when read aloud over the
telephone, it's clear enough.
If not, then it needs rewriting.
50. Choosing Good Names
Splitters can be lumped more easily
than lumpers can be split.
It is easier to combine two concepts
that it is to separate them.
70. Ubiquitous Language
applyPhq9DateRangeConstraint()
The PHQ-9 is the nine item depression scale of
the Patient Health Questionnaire.
The PHQ-9 is a powerful tool for assisting primary
care clinicians in diagnosing depression as well as
selecting and monitoring treatment.
73. Choosing Good Names
•Locate one
Naming'Guidelines
System'of'Names
S1# # Name#pass#the#“telephone”#test.
S2# # There#is#a#clean#name#for#each#concept.#Remember:#later#on#it’s#easier#to#lump#
guideline that if
things#together#than#to#split#them#apart.
S3# # Name#is#from#the#problem#or#solu?on#domain#and#support#ubiquitous#language#for#
the#team
General
applied would have
G1## Name#is#pronounceable.
G2## Name#avoids#encodings#and#member#prefixes.
G3## Name#suggest#why#it#exists.
G4## Name#suggest#how#it#should#be#used.
the biggest impact
G5## Name#suggest#what#it#does.
G6## Name#is#easily#searchable#in#the#code#base.
Classes
C1# If#this#is#an#important#base#class#its#class#name#should#be#a#simple#single#word.
C2#
C3#
If#this#is#a#subclass#its#class#name#suggests#how#it#differs#from#its#superclass.
The#class#name#is#a#noun#or#a#noun#phrase.
on your code
•Find a partner
Methods
M1# The#method#name#suggests#why#it#would#be#called.
M2# The#method#is#name#a#verb#or#a#verb#phrase.
Variables/Fields/Arguments
•Discuss
V1# Its#name#indicate#the#role#it's#playing.
V2# The#length#of#the#name#reflect#its#scope.
Alistair McKinnell @amckinnell Declan Whelan @dwhelan
Naming Guidelines v1.0 August 2012 ! 1/1
74. Choosing Good Names
public List<int[]> getThem() {
List<int[]> list1 = new ArrayList<int[]>();
for (int[] x : theList)
if (x[0] == 4)
list1.add(x);
return list1;
}
Source: Clean Code: A Handbook of Agile Software Craftsmanship, Robert C. Martin, pages 18-19
75. Choosing Good Names
public List<int[]> getThem() {
List<int[]> list1 = new ArrayList<int[]>();
for (int[] x : theList)
if (x[0] == 4)
list1.add(x);
return list1;
}
public List<int[]> getFlaggedCells() {
List<int[]> flaggedCells = new ArrayList<int[]>();
for (int[] cell : gameBoard)
if (cell[STATUS_VALUE] == FLAGGED)
flaggedCells.add(cell);
return flaggedCells;
}
Source: Clean Code: A Handbook of Agile Software Craftsmanship, Robert C. Martin, pages 18-19
76. Choosing Good Names
public List<int[]> getThem() {
List<int[]> list1 = new ArrayList<int[]>();
for (int[] x : theList)
if (x[0] == 4)
list1.add(x);
return list1;
}
public List<Cell> getFlaggedCells() {
List<Cell> flaggedCells = new ArrayList<Cell>();
for (Cell cell : gameBoard)
if (cell.isFlagged())
flaggedCells.add(cell);
return flaggedCells;
}
Source: Clean Code: A Handbook of Agile Software Craftsmanship, Robert C. Martin, pages 18-19
77. Choosing Good Names
public List<int[]> getThem() {
List<int[]> list1 = new ArrayList<int[]>();
for (int[] x : theList)
if (x[0] == 4)
list1.add(x);
return list1;
}
public List<Cell> getFlaggedCells() {
List<Cell> result = new ArrayList<Cell>();
for (Cell cell : gameBoard)
if (cell.isFlagged())
result.add(cell);
return result;
}
Source: Clean Code: A Handbook of Agile Software Craftsmanship, Robert C. Martin, pages 18-19
78. Choosing Good Names
int s = 0;
for (int j=0; j<34; j++) {
s += (t[j]*4)/5;
}
const int EFFECTIVE_DAYS_PER_WEEK = 4;
int realDaysPerIdealDay = 4;
const int WORKING_DAYS_PER_WEEK = 5;
const int WORK_DAYS_PER_WEEK = 5;
int sum = 0;
int effectiveTotalEstimate = 0;
for (int j=0; j < NUMBER_OF_TASKS; j++) {
for (int j=0; j < NUMBER_OF_TASKS; j++) {realDaysPerIdealDay;
int realTaskDays = taskEstimate[j] *
int effectiveTaskEstimate =
int realTaskWeeks = (realdays / WORK_DAYS_PER_WEEK);
taskEstimate[j] * EFFECTIVE_DAYS_PER_WEEK / WORKING_DAYS_PER_WEEK;
sum += realTaskWeeks;
effectiveTotalEstimate += effectiveTaskEstimate;
}
}
Source: Clean Code: A Handbook of Agile Software Craftsmanship, Robert C. Martin, page 23
84. How do you handle
duplicate code
in your codebase?
85.
86. Avoiding Duplicate Code
DRY: Don’t Repeat Yourself
Every piece of knowledge must have
a single, unambiguous, authoritative
representation within a system.
87. Avoiding Duplicate Code
Once and Only Once
Data, structure, or logic should exist
in only one place in the system.
88. Avoiding Duplicate Code
Test-Driven Development
1. Write new code only if an
automated test has failed.
2. Eliminate duplication.
89. Avoiding Duplicate Code
Single Choice Principle
Whenever a software system must
support a set of alternatives, one
and only one module in the system
should know their exhaustive list.
108. Select Options
SelectOptions SelectOptionsSource
create() getFirst()
getLast()
isSelected()
Commonality Variability Resolution
Data Structure Value of State Simple Java Type
131. “The prime directive that was
unanimously agree upon by all
present was that in the next
tens years Agile leaders must
Demand Technical Excellence.”
Jeff Sutherland
132. “Failure to do that means
you are not an Agile leader.”
Jeff Sutherland
134. Reading
The Elements of Programming Style
Kernighan and Plauger
Prefactoring
Extreme Abstraction Extreme Separation Extreme Readability
Ken Pugh
Pragmatic
Programmers Agile in a Flash
Speed-Learning Agile
Software Development
Agile in a Flash
Agile Cards for
Agile Teams Speed-Learning Agile Development
Jeff Langr and
Tim Ottinger
edited by Susannah Pfalzer
Jeff Langr and Tim Ottinger
Prepared exclusively for Alistair McKinnell
135. Reading
Clean Code
A Handbook of Agile Software Craftsmanship
Robert C. Martin
Domain Driven Design
Tackling Complexity in the Heart of Software
Eric Evans
Implementation Patterns
Kent Beck
136. Reading
The Pragmatic Programmer: From Journeyman to Master
Andrew Hunt and Dave Thomas
Extreme Programming Explained: Embrace Change
Kent Beck and Cynthia Andres
Test Driven Development: By Example
Kent Beck
Object-Oriented Software Construction
Bertrand Meyer
137. Reading
Design Patterns: Elements of Reusable
Object-Oriented Software Erich Gamma,
Richard Helm, Ralph Johnson, and John Vlissides
Multi-Paradigm Design for C++
James O. Coplien
Lean Architecture: for Agile Software Development
James O. Coplien and Gertrud Bjørnvig