Presented at NDC 2014 in Oslo (4th June 2014)
Video available on Vimeo: https://vimeo.com/97329157
Habits help you manage the complexity of code. You apply existing skill and knowledge automatically to the detail while focusing on the bigger picture. But because you acquire habits largely by imitation, and rarely question them, how do you know your habits are effective? Many of the habits that programmers have for naming, formatting, commenting and unit testing do not stand up as rational and practical on closer inspection.
This talk examines seven coding habits that are not as effective as programmers believe, and suggests alternatives.
(video and more at http://fsharpforfunandprofit.com/fppatterns)
In object-oriented development, we are all familiar with design patterns such as the Strategy pattern and Decorator pattern, and design principles such as SOLID. The functional programming community has design patterns and principles as well. This talk will provide an overview of some of these patterns (such as currying, monads), and present some demonstrations of FP design in practice. We'll also look at some of the ways you can use these patterns as part of a domain driven design process, with some simple real world examples in F#. No jargon, no maths, and no prior F# experience necessary.
JavaScript has some stunning features like Closures, Prototype etc. which can help to improve the readability and maintainability of the code. However, it is not easy for inexperienced developer to consume and apply those features in day to day coding. The purpose of the presentation ‘Advanced JavaScript’ is to help a reader easily understand the concept and implementation of some advanced JavaScript features.
(video and more at http://fsharpforfunandprofit.com/fppatterns)
In object-oriented development, we are all familiar with design patterns such as the Strategy pattern and Decorator pattern, and design principles such as SOLID. The functional programming community has design patterns and principles as well. This talk will provide an overview of some of these patterns (such as currying, monads), and present some demonstrations of FP design in practice. We'll also look at some of the ways you can use these patterns as part of a domain driven design process, with some simple real world examples in F#. No jargon, no maths, and no prior F# experience necessary.
JavaScript has some stunning features like Closures, Prototype etc. which can help to improve the readability and maintainability of the code. However, it is not easy for inexperienced developer to consume and apply those features in day to day coding. The purpose of the presentation ‘Advanced JavaScript’ is to help a reader easily understand the concept and implementation of some advanced JavaScript features.
10 years after the release of the original book Domain Driven Design by Eric Evans we are seeing more and more applications built on the core concepts of DDD. Still, there is a long way to go before we fully grasp all its potential. First we need to change the way we do things in our projects. In this session I will show a possible implementation in C# that I've been using in many projects.
All 3 Clean Code presentations provide great value by themselves, but taken together are designed to offer a holistic approach to successful software creation. This first session creates the foundation for the 2nd and 3rd Clean Code presentation on Dependency Injection, as it explains expected base knowledge. Why writing Clean Code makes us more efficient Over the lifetime of a product, maintaining the product is actually one - if not the most - expensive area(s) of the overall product costs.
Writing clean code can significantly lower these costs. However, writing clean code also makes you more efficient during the initial development time and results in more stable code. You will be presented design patterns and best practices which will make you write better and more easily maintainable code, seeing code in a holistic way.
You will learn how to apply them by using an existing implementation as the starting point of the presentation. Finally, patterns & practices benefits are explained. This presentation is based on C# and Visual Studio 2012. However, the demonstrated patterns and practice can be applied to every other programming language too.
Note: Moving forwards this presentation will be updated with the latest version of the slides for the last event I did the presentation instead of creating new separate slide decks here on SlideShare.
Presentation dates and locations:
2015-10-03 Silicon Valley Code Camp, San Jose, CA
2015-06-27 SoCal Code Camp - San Diego, CA
2014-11-14 SoCal Code Camp - Los Angeles, CA
2014-10-18 Desert Code Camp - Chandler, AZ
2014-10-11 Silicon Valley Code Camp, Los Altos Hills, CA
Towards Functional Programming through Hexagonal ArchitectureCodelyTV
Slides of for the talk "Towards Functional Programming through Hexagonal Architecture" delivered at the Software Crafters Barcelona 2018 conference #scbcn18 by Juanma Serrano from Habla Computing and Javier Ferrer from CodelyTV
Functional programming can be an excellent approach to designing decoupled, reusable systems with a rich domain model. In fact, the lessons from applying DDD in a functional language translate well to object-oriented programming.
Jobs to be Done is best described as a perspective through which new product ideas can be evaluated for usefulness and viability. Understanding your customers’ Jobs to be Done helps determine what specific needs, pain points, or problems to focus on during the innovation process.
The theory of Jobs to be Done was developed by Tony Ulwick and later by Clayton Christensen of Harvard Business School as a complement to his theory of disruptive innovation. Jobs to be Done is a lens through which companies can view their innovation initiatives. People buy products and services to get a “job” done, and the products that are successful are those which help the customer get a job done faster, more easily and less expensively. When a company understands in detail what a functional job is, it is more likely to be able to create solutions to help the customer get a job done more effectively. When the customer can get a job done more easily with a given product, the product will likely be more successful.
Use the templates to identify your customers’ most important jobs to be done and then rank order them to determine the most important jobs to address as part of your innovation efforts.
Google is adding Kotlin as an official programming language for Android development. Kotlin is a language that runs on the JVM and has full interoperability with Java. It costs nothing to adopt! I will show some cool features of Kotlin, how it makes developing with Android easy and finally we'll see what happens under the hood when we write in Kotlin.
CONSTRUCTOR AND DESTRUCTOR PPT BASED ON OOP SUBJECT ......FULLY CONCEPT EXPLAINED WITH SAMPLE PROGRAM IN IT .....FOR MORE SLIDES PLEASE FOLLOW ME ..... THANK YOU
Seven Ineffective Coding Habits of Many ProgrammersKevlin Henney
Presented at NorDevCon (27th February 2015)
Habits help you manage the complexity of code. You apply existing skill and knowledge automatically to the detail while focusing on the bigger picture. But because you acquire habits largely by imitation, and rarely question them, how do you know your habits are effective? Many of the habits that programmers have for naming, formatting, commenting and unit testing do not stand up as rational and practical on closer inspection.
This talk examines seven coding habits that are not as effective as programmers believe, and suggests alternatives.
7 ineffective coding habits many F# programmers don't haveYan Cui
At BuildStuff'14, Kevlin Henney presented an excellent talk titled "Seven ineffective coding habits of many programmers". As an attendee that day and someone who has exhibited many of these habits over the years, I came to realize that using F# has cured me of many of these ineffective habits! In this talk I'll share my thoughts on how the use of F# and functional programming techniques can help form and nurture good habits and give you the perfect practice you need to make perfect.
10 years after the release of the original book Domain Driven Design by Eric Evans we are seeing more and more applications built on the core concepts of DDD. Still, there is a long way to go before we fully grasp all its potential. First we need to change the way we do things in our projects. In this session I will show a possible implementation in C# that I've been using in many projects.
All 3 Clean Code presentations provide great value by themselves, but taken together are designed to offer a holistic approach to successful software creation. This first session creates the foundation for the 2nd and 3rd Clean Code presentation on Dependency Injection, as it explains expected base knowledge. Why writing Clean Code makes us more efficient Over the lifetime of a product, maintaining the product is actually one - if not the most - expensive area(s) of the overall product costs.
Writing clean code can significantly lower these costs. However, writing clean code also makes you more efficient during the initial development time and results in more stable code. You will be presented design patterns and best practices which will make you write better and more easily maintainable code, seeing code in a holistic way.
You will learn how to apply them by using an existing implementation as the starting point of the presentation. Finally, patterns & practices benefits are explained. This presentation is based on C# and Visual Studio 2012. However, the demonstrated patterns and practice can be applied to every other programming language too.
Note: Moving forwards this presentation will be updated with the latest version of the slides for the last event I did the presentation instead of creating new separate slide decks here on SlideShare.
Presentation dates and locations:
2015-10-03 Silicon Valley Code Camp, San Jose, CA
2015-06-27 SoCal Code Camp - San Diego, CA
2014-11-14 SoCal Code Camp - Los Angeles, CA
2014-10-18 Desert Code Camp - Chandler, AZ
2014-10-11 Silicon Valley Code Camp, Los Altos Hills, CA
Towards Functional Programming through Hexagonal ArchitectureCodelyTV
Slides of for the talk "Towards Functional Programming through Hexagonal Architecture" delivered at the Software Crafters Barcelona 2018 conference #scbcn18 by Juanma Serrano from Habla Computing and Javier Ferrer from CodelyTV
Functional programming can be an excellent approach to designing decoupled, reusable systems with a rich domain model. In fact, the lessons from applying DDD in a functional language translate well to object-oriented programming.
Jobs to be Done is best described as a perspective through which new product ideas can be evaluated for usefulness and viability. Understanding your customers’ Jobs to be Done helps determine what specific needs, pain points, or problems to focus on during the innovation process.
The theory of Jobs to be Done was developed by Tony Ulwick and later by Clayton Christensen of Harvard Business School as a complement to his theory of disruptive innovation. Jobs to be Done is a lens through which companies can view their innovation initiatives. People buy products and services to get a “job” done, and the products that are successful are those which help the customer get a job done faster, more easily and less expensively. When a company understands in detail what a functional job is, it is more likely to be able to create solutions to help the customer get a job done more effectively. When the customer can get a job done more easily with a given product, the product will likely be more successful.
Use the templates to identify your customers’ most important jobs to be done and then rank order them to determine the most important jobs to address as part of your innovation efforts.
Google is adding Kotlin as an official programming language for Android development. Kotlin is a language that runs on the JVM and has full interoperability with Java. It costs nothing to adopt! I will show some cool features of Kotlin, how it makes developing with Android easy and finally we'll see what happens under the hood when we write in Kotlin.
CONSTRUCTOR AND DESTRUCTOR PPT BASED ON OOP SUBJECT ......FULLY CONCEPT EXPLAINED WITH SAMPLE PROGRAM IN IT .....FOR MORE SLIDES PLEASE FOLLOW ME ..... THANK YOU
Seven Ineffective Coding Habits of Many ProgrammersKevlin Henney
Presented at NorDevCon (27th February 2015)
Habits help you manage the complexity of code. You apply existing skill and knowledge automatically to the detail while focusing on the bigger picture. But because you acquire habits largely by imitation, and rarely question them, how do you know your habits are effective? Many of the habits that programmers have for naming, formatting, commenting and unit testing do not stand up as rational and practical on closer inspection.
This talk examines seven coding habits that are not as effective as programmers believe, and suggests alternatives.
7 ineffective coding habits many F# programmers don't haveYan Cui
At BuildStuff'14, Kevlin Henney presented an excellent talk titled "Seven ineffective coding habits of many programmers". As an attendee that day and someone who has exhibited many of these habits over the years, I came to realize that using F# has cured me of many of these ineffective habits! In this talk I'll share my thoughts on how the use of F# and functional programming techniques can help form and nurture good habits and give you the perfect practice you need to make perfect.
Seven Ineffective Coding Habits of Many Java ProgrammersKevlin Henney
Presented at GeeCON (15th May 2014)
Video available on Vimeo: https://vimeo.com/101084305
Habits help you manage the complexity of code. You apply existing skill and knowledge automatically to the detail while focusing on the bigger picture. But because you acquire habits largely by imitation, and rarely question them, how do you know your habits are effective? Many of the habits and conventions Java programmers have for naming, formatting, commenting and unit testing do not stand up as rational and practical on closer inspection.
This session examines seven coding habits that are not as effective as many Java programmers believe, and suggests alternatives.
Mistakes happen - no matter how experienced you are. Using Git as your version control system, however, you have a safety net that helps you if it comes to the worst. Learn how to undo, roll back, and recover from mistakes.
The main body of work related to supporting dynamic languages on the JVM at Oracle today is done within the Nashorn project. While on the surface it looks like we're busy creating a JavaScript runtime, in reality JavaScript is only the beginning, and not the ultimate goal. Nashorn has served as the proving ground for new approaches for implementing a dynamic language on top of the JVM, and we're eager to – once solidified – crystallize these into a reusable dynamic language implementer's toolkit. We have faced challenges of optimally mapping JavaScript local variables to JVM types (or: "hey, there's a static type inference algorithm in your dynamic language compiler"), doing liveness analysis, cutting up methods too large to fit into a single JVM method, efficiently representing large array and object literals in compiled code, creating a system for on-demand compilation of several type-specialized variants of the same function, and more. Along the way, we have reached the limits of our initial internal representation (fun fact: you can't do liveness analysis on an AST. We learned it the hard way.) and started sketching up an intermediate representation that would be easy to emit from a dynamic language compiler, and that could be taken over by a toolchain to perform the operations described above then on it and finally output standard Java bytecode for JIT to take over. Elevator pitch: like LLVM, but for dynamic languages on the JVM.
Bare Metal to OpenStack with Razor and ChefMatt Ray
Slides from the OpenStack Spring 2013 Summit workshop presented by Egle Sigler (@eglute) and Matt Ray (@mattray) from Rackspace and Opscode respectively. Please refer to http://anystacker.com/ for additional content.
Escalating complexity: DevOps learnings from Air France 447Lindsay Holmwood
On June 1, 2009 Air France 447 crashed into the Atlantic ocean killing all 228 passengers and crew. The 15 minutes leading up to the impact were a terrifying demonstration of the how thick the fog of war is in complex systems.
Mainstream reports of the incident put the blame on the pilots - a common motif in incident reports that conveniently ignore a simple fact: people were just actors within a complex system, doing their best based on the information at hand.
While the systems you build and operate likely don't control the fate of people's lives, they share many of the same complexity characteristics. Dev and Ops can learn an abundance from how the feedback loops between these aviation systems are designed and how these systems are operated.
In this talk Lindsay will cover what happened on the flight, why the mainstream explanation doesn't add up, how design assumptions can impact people's ability to respond to rapidly developing situations, and how to improve your operational effectiveness when dealing with rapidly developing failure scenarios.
Distributed Consensus A.K.A. "What do we eat for lunch?"Konrad Malawski
Distributed Consensus is everywhere! Even if not obvious at first, most apps nowadays are distributed systems, and these sometimes have to "agree on a value", this is where consensus algorithms come in. In this session we'll look at the general problem and solve a few example cases using the RAFT algorithm implemented using Akka's Actor and Cluster modules.
Presentation on Lean Analytics at MicroConf 2013. Understanding what metrics are the most value, when, for your type of business.
* What makes a good metric?
* Types of metrics (qualitative vs. quantitative, vanity vs. actionable, etc.)
* Lean Analytics framework
Shared a number of case studies: Airbnb, Buffer, ClearFit, OffceDrop and others.
The slides of my talk at PUGRoma.
Here, a complete sample code
https://github.com/leopro/trip-planner
Presentation is also here: http://t.co/5EK56yYBmQ
Seven Ineffective Coding Habits of Many ProgrammersKevlin Henney
Presented at Build Stuff (20th November 2014)
Habits help you manage the complexity of code. You apply existing skill and knowledge automatically to the detail while focusing on the bigger picture. But because you acquire habits largely by imitation, and rarely question them, how do you know your habits are effective? Many of the habits and conventions programmers have for naming, formatting, commenting and unit testing do not stand up as rational and practical on closer inspection.
This session examines seven coding habits that are not as effective as many programmers — whether working with Java, .NET, native or scripting languages — might believe, and suggests alternatives.
Seven Ineffective Coding Habits of Many ProgrammersKevlin Henney
Presented at DevTernity (1st December 2016)
Video available at https://www.youtube.com/watch?v=SUIUZ09mnwM
Habits help you manage the complexity of code. You apply existing skill and knowledge automatically to the detail while focusing on the bigger picture. But because you acquire habits largely by imitation, and rarely question them, how do you know your habits are effective? Many of the habits that programmers have for naming, formatting, commenting and unit testing do not stand up as rational and practical on closer inspection. This talk examines seven coding habits that are not as effective as programmers believe, and suggests alternatives.
Most of us started with patterns by Eric Evans and others. This helped us build models using Object Orientated Design and we have grown to appreciate the value of patterns such as Aggregate and Value Object. This talk looks forward and consists of various attempts to push our boundaries towards a more declarative way of domain modelling. We will look at a functional and logic based approach to design, where the statement of the requirement is the model itself. Apart from the variable choices in programming languages, the thinking tools that arise from this helps reduces the impedance between programmers and domain experts. The intention of this talk is to share, generate conversation so that we move forward as a community.
Presented at .NET South West (2017-07-25)
Code is basically made up of three things: names, spacing and punctuation. With these three tools a programmer needs to communicate intent, and not simply instruct. But if we look at most approaches to naming, they are based on the idea that names are merely labels, so that discussion of identifier naming becomes little more than a discussion of good labelling.
A good name is more than a label; a good name should change the way the reader thinks. A good name should describe structure with intention, as opposed to the affix-heavy approach common to many naming conventions in current use, where the addition of more prefixes and suffixes becomes homeopathic, diluting the meaning. Good naming is part of good design. This session looks at why and what it takes to get a good name.
Incompleteness Theorems: Logical Necessity of InconsistencyCarl Hewitt
These are slides for video of "Wittgenstein versus Gödel on the Foundations of Logic" Stanford Logic Colloquium on April 23, 2010.
Video can be viewed at:
http://wh-stream.stanford.edu/MediaX/CarlHewittEdit.mp4
Why Agile Works But Isn't Working For YouDavid Harvey
Presentation for Causerie at ADMB Bruges, Thursday 12 February 2009.
Audio will be added once I have it - the pictures are nice, but I'm not sure they make that much sense without the narrative (or do they? What do you think?)
(NB first slide is not a mistake - deliberately empty)
Presented at SwanseaCon (2017-09-26)
We default to considering systems from an insider's perspective; the view from outside can be quite different. Can we apply this inversion to more than just requirements?
We may say we want testing, but what do we want from testing? We may say we want logging, but what do we want from logging? We may say we want clean code, but what do we want from clean code? We may say we want an agile process, but what do we want from an agile process? These are harder questions, but their answers can make for better solutions.
Mike Kotsur - What can philosophy teach us about programming - Codemotion Ams...Codemotion
If Socrates met Linus Torvalds, what would they talk about? How much math should be bundled into a good programming language? Can compiler resolve an argument and prove, that someone is right? Trough semantics of code, that we write every day, when looking carefully, one can see foundations of logic and science, that has been build more than 2000 years ago. Why does it matter, and how can we leverage this enormous power to make our code safe and sound in languages with advanced type systems, like Typescript and Scala.
Presented at JavaZone (9th September 2015)
Video available at https://vimeo.com/138863968
The three-act play, the given–when–then BDD triptych, the three steps of the Feynman problem-solving algorithm... a surprising number of things appear to come in threes. This talk walks through — and has some fun with — a number of triples that affect and are found in software development.
DN18 | A/B Testing: Lessons Learned | Dan McKinley | MailchimpDataconomy Media
Abstract about the Presemtation:
Introducing A/B testing to a large team that has never done it before is a weird and bewildering thing that Dan McKinley has somehow done twice. This has burdened him with many opinions about how to achieve this with minimal wailing and gnashing of teeth.
About the Author:
Dan McKinley is a Co-Founder of Skyliner in Los Angeles. Previously he worked at Stripe and spent nearly 7 years building Etsy, during which he worked on “pretty much every feature and backend facility on the site”. He resides in LA with his wife and son.
Presented at .NET South West (2024-03-26)
https://www.meetup.com/dotnetsouthwest/events/299766807/
One of the greatest shifts in modern programming practices has been how programmers across many different domains, languages and environments have embraced unit testing. Good unit testing, however, is more than waving NUnit at your C# source. Tests help to make long-term product development cost effective rather than a cost centre, they underpin the effective flow of CI/CD and reduce failure demand on a team.
But the discussion of unit testing goes further than simply writing tests: what makes a good unit test? It is not enough to have tests; poor quality tests can hold back development just as good tests can streamline it. This session provides a perspective on what good unit tests (GUTs) can look like with a couple of examples.
Presented at Agile meets Architecture (2023-10-05)
Video at https://www.youtube.com/watch?v=LLEXAdO3X1o
One of the (most overlooked) principles of the Manifesto for Agile Software Development is that "Continuous attention to technical excellence and good design enhances agility". All too often, work that focuses on addressing technical issues is deprioritised in the name of focusing on business value.
Is there a case for technical excellence — in code, in architecture, in people — beyond its appearance on a might-as-well-be-hidden page on a manifesto that's over two decades old? Is technical excellence only the concern of technical roles? Is a good architecture in conflict with business value or a vehicle for it?
This session looks to go beyond buzzwords to build a case for technical excellence that appeals to all roles in a development organisation, noting that "The best architectures, requirements, and designs emerge from self-organizing teams".
Presented online for Build Stuff meetup (https://www.buildstuff.events/events/online-build-stuff-meetup-with-kevlin-henney-and-cassandra-faris)
Whether we are talking about software architecture, coding practices or our development process, it's important to keep it real. All too often we find ourselves attracted to ideas that sound great in theory, but may not work out in practice. All too often we assume we are right — the planned release schedule, the key architectural decisions, the good practices we saw in a blog — but fail to adjust for reality. We fail to acknowledge that our knowledge was incomplete or that the situation has changed, sticking to the plan and practice regardless.
In this talk we will look at what an empirical approach to development means in practice, why it is that up-front architecture is risky and expensive, why it is that most teams who say they're doing agile development are not, and how we can use uncertainty and instability to structure our time and our code.
Presented online for C++ on Sea (2020-07-17)
Video at https://www.youtube.com/watch?v=Bai1DTcCHVE
Lambdas. All the cool kid languages have them. But does lambda mean what C++ and other languages, from Java to Python, mean by lambda? Where did lambdas come from? What were they originally for? What is their relationship to data abstraction?
In this session we will into the history, the syntax, the uses and abuses of lambdas and the way in which lambda constructs in C++ and other languages do (or do not) match the original construct introduced in lambda calculus.
Presented online for javaBin (2020-04-14)
Video at https://www.youtube.com/watch?v=orcSUE0Jjdc
Lambdas. All the cool kid languages have them. But does ‘lambda’ mean what Java, JavaScript, etc. mean by ‘lambda’? Where did lambdas come from? What were they originally for? What is their relationship to data abstraction?
In this session we will look into the history, the syntax and the uses of lambdas and the way in which lambda constructs in Java and other languages do (or do not) match the original construct introduced in lambda calculus.
Presented at DevSum (2018-05-31)
The SOLID principles are often presented as being core to good code design practice. Each of S, O, L, I and D do not, however, necessarily mean what programmers expect they mean or are taught. By understanding this range of beliefs we can learn more about practices for objects, components and interfaces than just S, O, L, I and D.
This talk reviews the SOLID principles and reveals contradictions and different interpretations. It is through paradoxes and surprises we often gain insights. We will leave SOLID somewhat more fluid, but having learnt from them more than expected.
Presented at Foo Café (2019-03-21)
Video at https://www.youtube.com/watch?v=tLSKLLxrZyY
Programmers use coding katas to kick the tyres of their programming languages, paradigms and practices. Typically anchored in a TDD cycle, katas are simple problems that give programmers the opportunity to exercise deliberate practice and explore different approaches, whether programming style, pair programming or test-first programming.
But the simplicity can be deceptive, with many programmers tiring of these katas too soon, missing out on some of the more mind-bending and paradigm-expanding opportunities on offer.
This session will pick on a couple of katas and dig deeper into TDD, lambdas, language(s), (dys)functional programming and Alcubierre drive. It will present code in a variety of languages, highlight the weaknesses of some common mantras, play around with ideas — and blend code, humour and general nerdiness to be both an enjoyable and educational session.
Procedural Programming: It’s Back? It Never Went AwayKevlin Henney
Presented at ACCU Conference 2018 (2018-04-12)
Video at https://www.youtube.com/watch?v=mrY6xrWp3Gs
When programmers describe code as 'procedural', it’s generally not meant as a compliment. There is a belief that we have collectively moved pass such thinking and onto better paradigms. But a paradigm is no more than a pattern language, a family of solutions fit for a context. Change the kind of problem you are solving and you may find a different solution makes sense — even, in these days where pure functions battle it out with classy objects, procedural programming.
This talk takes a look at some of the past, present and future of procedural programming, looking at how there’s more to it than many first assume, how it has informed and continues to influence language design and how it relates to other paradigms, such as functional and OO.
Structure and Interpretation of Test CasesKevlin Henney
Presented at ACCU Cambridge (2018-10-23)
Throw a line of code into many codebases and it's sure to hit one or more testing frameworks. There's no shortage of frameworks for testing, each with their particular spin and set of conventions, but that glut is not always matched by a clear vision of how to structure and use tests — a framework is a vehicle, but you still need to know how to drive. The computer science classic, Structure and Interpretation of Computer Programs, points out that "Programs must be written for people to read, and only incidentally for machines to execute". The same is true of test code.
This talk takes a deep dive into unit testing, looking at examples and counterexamples across a number of languages and frameworks, from naming to nesting, exploring the benefits of data-driven testing, the trade-offs between example-based and property-based testing, how to get the most out of the common given–when–then refrain and knowing how far to follow it.
Keynote present at Agile Tour Vienna (2018-10-06)
Velocity. Sprints. More points, more speed. An obsession with speed often overtakes the core values of agile software development. It’s not just development of software; it’s development of working software. Sprints are not about sprinting; they’re about sustainable pace. Time to market is less important than time in market. Full-stack development is normally a statement about technology, but it also applies to individuals and interactions. The full stack touches both the code and the world outside the code, and with that view comes responsibility and pause for thought. Doing the wrong thing smarter is not smart. The point of a team is its group intelligence not its numbers. Is scaling up the challenge, or is scaling down the real challenge? The distraction and misuse of speed, velocity, point-based systems, time, team size, scale, etc. is not the accelerant of agile development. Agility lies in experimentation, responsiveness and team intelligence.
Keynote presented at NewCrafts (2018-06-18)
Video available at https://vimeo.com/276832516
It has been said that immutability changes everything. But what does that mean in practice? What does it mean for existing code that looks more like the mutant apocalypse than an elegant application of mathematical thinking? Immutability can be an ideal that is hard to reach. Refactoring, on the other hand, is all about the art of the possible. In this talk we'll be clarifying motivation and exploring some approaches to help reducing state mutability in code.
Keynote presented at GOTO Chicago (2018-04-26)
Video available at https://www.youtube.com/watch?v=AbgsfeGvg3E
Everything is changing. Everything is new. Frameworks, platforms and trends are displaced on a weekly basis. Skills are churning.
And yet... Beneath this seemingly turbulent flow there is a slow current, strong and steady, changing relatively little over the decades. Concepts with a long history appear in new forms and fads and technologies. Principles are revisited. Ideas once lost to the mainstream are found again.
In this keynote we revisit the present through the past, looking at the enduring principles that shape programming languages, architecture, development practice and development process, the ideas that cycle round, each time becoming perhaps a little better defined, a little more mature, and look to see what else might be on the horizon.
Clean Coders Hate What Happens To Your Code When You Use These Enterprise Pro...Kevlin Henney
Presented at code::dive (2016-11-15)
Video available at https://www.youtube.com/watch?v=brfqm9k6qzc
It is all to easy to dismiss problematic codebases on some nebulous idea of bad practice or bad programmers. Poor code, however, is rarely arbitrary and random in its structure or formulation. Systems of code, well or poorly structured, emerge from systems of practice, whether effective or ineffective. To improve code quality, it makes more sense to pick apart the specific practices and see their interplay — the cause — than to simply focus on the code itself — the effect. This talk looks at how a handful of coding habits, design practices and assumptions can systematically balloon code and compound its accidental complexity.
Thinking Outside the Synchronisation QuadrantKevlin Henney
Presented at code::dive (2016-11-16)
Video available at https://www.youtube.com/watch?v=yl25p91flLY
Ask programmers what comes to mind when you say concurrency and most are likely to say threads. Ask what comes to mind when you say threads and most are likely to say locks or synchronisation. These assumptions are so deeply held that they define and constrain how programmers are taught and think about concurrency: thread safety is almost synonymous with the avoidance of race conditions and the guarded protection of mutable state. But this is only one quadrant of four possibilities, a quadrant diagram partitioned by mutable–immutable along one axis and shared–unshared along another. Modern C++ supports programmers in all four quadrants, not just the synchronisation quadrant. From immutability to actors, this talk will take a look at patterns and practices that encourage thinking and coding outside the locked box.
Presented at GOTO Amsterdam (2017-06-13)
Video available at https://www.youtube.com/watch?v=YyhfK-aBo-Y
What is risk? Many people aren't sure, but it's not just uncertainty: risk is exposure to uncertainty.
Instead of just plastering over the cracks, security should also involve reducing the size and number of cracks, reducing the opportunities for cracks to appear, reducing the class of errors and oversights that can open a system to failure instigated from the outside. We can learn a lot from other kinds of software failure, because every failure unrelated to security can be easily reframed as a security-failure opportunity.
This is not a talk about access control models, authentication, encryption standards, firewalls, etc. This is a talk about reducing risk that lives in the code and the assumptions of architecture, reducing the risk in development practices and in the blind spot of development practices.
Keynote presented at SATURN (2nd May 2017)
Video available at https://www.youtube.com/watch?v=MS3c9hz0bRg
"It's just a detail." Have you ever said that or been told that? Whether it's about implementation or requirements, we often use the word detail to suggest that something is not important enough to worry about. There are so many things to worry about in software development that we need to prioritize—too much detail, not enough focus. The problem is that in software, the details matter because that is what software is: lots of details brought together in combination. If we don't focus on the details, we get debt, defects, and delays.
Presented at Agile Bath & Bristol (21st March 2017)
If software development is a co-operative game, as Alistair Cockburn observed, then what kind of game is Scrum? Lots of people are playing it — or say they are — but there seems to be some disagreement about what the point of the game is, how to play it and even, in many cases, what the rules are. This talk looks at Scrum and other agile approaches through the lens of nomic games, hypothesis-driven development and fun.
Presented at the European Bioinformatics Institute (17th March 2017)
We often talk about good code — that we would like to write it, that there isn't enough of it, that it should not be considered an optional attribute of a codebase. We often talk about it but, when it comes to being precise, we don't always agree what constitutes good code, nor do we necessarily share a common view on its value.
Keynote presented at European Testing Conference (9th February 2017)
What happens when things break? What happens when software fails? We regard it as a normal and personal inconvenience when apps crash or servers become unavailable, but what are the implications beyond the individual user? Is software reliability simply a business decision or does it have economic, social and cultural consequences? What are the moral and practical implications for software developers? And when we talk of ‘systems’, are we part of the ‘system’? What about the bugs on our side of the keyboard? In this talk we will explore examples of failures in software and its application, and how they affect us at different scales, from user to society.
Presented at GOTO Nights (20th September 2016)
The SOLID principles are often presented as being core to good code design practice. Each of S, O, L, I and D do not, however, necessarily mean what programmers expect they mean or are taught. By understanding this range of beliefs we can learn more about practices for objects, components and interfaces than just S, O, L, I and D.
This talk reviews the SOLID principles and reveals contradictions and different interpretations. It is through paradoxes and surprises we often gain insights. We will leave SOLID somewhat more fluid, but having learnt from them more than expected.
Key Trends Shaping the Future of Infrastructure.pdfCheryl Hung
Keynote at DIGIT West Expo, Glasgow on 29 May 2024.
Cheryl Hung, ochery.com
Sr Director, Infrastructure Ecosystem, Arm.
The key trends across hardware, cloud and open-source; exploring how these areas are likely to mature and develop over the short and long-term, and then considering how organisations can position themselves to adapt and thrive.
Securing your Kubernetes cluster_ a step-by-step guide to success !KatiaHIMEUR1
Today, after several years of existence, an extremely active community and an ultra-dynamic ecosystem, Kubernetes has established itself as the de facto standard in container orchestration. Thanks to a wide range of managed services, it has never been so easy to set up a ready-to-use Kubernetes cluster.
However, this ease of use means that the subject of security in Kubernetes is often left for later, or even neglected. This exposes companies to significant risks.
In this talk, I'll show you step-by-step how to secure your Kubernetes cluster for greater peace of mind and reliability.
UiPath Test Automation using UiPath Test Suite series, part 4DianaGray10
Welcome to UiPath Test Automation using UiPath Test Suite series part 4. In this session, we will cover Test Manager overview along with SAP heatmap.
The UiPath Test Manager overview with SAP heatmap webinar offers a concise yet comprehensive exploration of the role of a Test Manager within SAP environments, coupled with the utilization of heatmaps for effective testing strategies.
Participants will gain insights into the responsibilities, challenges, and best practices associated with test management in SAP projects. Additionally, the webinar delves into the significance of heatmaps as a visual aid for identifying testing priorities, areas of risk, and resource allocation within SAP landscapes. Through this session, attendees can expect to enhance their understanding of test management principles while learning practical approaches to optimize testing processes in SAP environments using heatmap visualization techniques
What will you get from this session?
1. Insights into SAP testing best practices
2. Heatmap utilization for testing
3. Optimization of testing processes
4. Demo
Topics covered:
Execution from the test manager
Orchestrator execution result
Defect reporting
SAP heatmap example with demo
Speaker:
Deepak Rai, Automation Practice Lead, Boundaryless Group and UiPath MVP
UiPath Test Automation using UiPath Test Suite series, part 3DianaGray10
Welcome to UiPath Test Automation using UiPath Test Suite series part 3. In this session, we will cover desktop automation along with UI automation.
Topics covered:
UI automation Introduction,
UI automation Sample
Desktop automation flow
Pradeep Chinnala, Senior Consultant Automation Developer @WonderBotz and UiPath MVP
Deepak Rai, Automation Practice Lead, Boundaryless Group and UiPath MVP
GDG Cloud Southlake #33: Boule & Rebala: Effective AppSec in SDLC using Deplo...James Anderson
Effective Application Security in Software Delivery lifecycle using Deployment Firewall and DBOM
The modern software delivery process (or the CI/CD process) includes many tools, distributed teams, open-source code, and cloud platforms. Constant focus on speed to release software to market, along with the traditional slow and manual security checks has caused gaps in continuous security as an important piece in the software supply chain. Today organizations feel more susceptible to external and internal cyber threats due to the vast attack surface in their applications supply chain and the lack of end-to-end governance and risk management.
The software team must secure its software delivery process to avoid vulnerability and security breaches. This needs to be achieved with existing tool chains and without extensive rework of the delivery processes. This talk will present strategies and techniques for providing visibility into the true risk of the existing vulnerabilities, preventing the introduction of security issues in the software, resolving vulnerabilities in production environments quickly, and capturing the deployment bill of materials (DBOM).
Speakers:
Bob Boule
Robert Boule is a technology enthusiast with PASSION for technology and making things work along with a knack for helping others understand how things work. He comes with around 20 years of solution engineering experience in application security, software continuous delivery, and SaaS platforms. He is known for his dynamic presentations in CI/CD and application security integrated in software delivery lifecycle.
Gopinath Rebala
Gopinath Rebala is the CTO of OpsMx, where he has overall responsibility for the machine learning and data processing architectures for Secure Software Delivery. Gopi also has a strong connection with our customers, leading design and architecture for strategic implementations. Gopi is a frequent speaker and well-known leader in continuous delivery and integrating security into software delivery.
Connector Corner: Automate dynamic content and events by pushing a buttonDianaGray10
Here is something new! In our next Connector Corner webinar, we will demonstrate how you can use a single workflow to:
Create a campaign using Mailchimp with merge tags/fields
Send an interactive Slack channel message (using buttons)
Have the message received by managers and peers along with a test email for review
But there’s more:
In a second workflow supporting the same use case, you’ll see:
Your campaign sent to target colleagues for approval
If the “Approve” button is clicked, a Jira/Zendesk ticket is created for the marketing design team
But—if the “Reject” button is pushed, colleagues will be alerted via Slack message
Join us to learn more about this new, human-in-the-loop capability, brought to you by Integration Service connectors.
And...
Speakers:
Akshay Agnihotri, Product Manager
Charlie Greenberg, Host
Smart TV Buyer Insights Survey 2024 by 91mobiles.pdf91mobiles
91mobiles recently conducted a Smart TV Buyer Insights Survey in which we asked over 3,000 respondents about the TV they own, aspects they look at on a new TV, and their TV buying preferences.
Builder.ai Founder Sachin Dev Duggal's Strategic Approach to Create an Innova...Ramesh Iyer
In today's fast-changing business world, Companies that adapt and embrace new ideas often need help to keep up with the competition. However, fostering a culture of innovation takes much work. It takes vision, leadership and willingness to take risks in the right proportion. Sachin Dev Duggal, co-founder of Builder.ai, has perfected the art of this balance, creating a company culture where creativity and growth are nurtured at each stage.
JMeter webinar - integration with InfluxDB and GrafanaRTTS
Watch this recorded webinar about real-time monitoring of application performance. See how to integrate Apache JMeter, the open-source leader in performance testing, with InfluxDB, the open-source time-series database, and Grafana, the open-source analytics and visualization application.
In this webinar, we will review the benefits of leveraging InfluxDB and Grafana when executing load tests and demonstrate how these tools are used to visualize performance metrics.
Length: 30 minutes
Session Overview
-------------------------------------------
During this webinar, we will cover the following topics while demonstrating the integrations of JMeter, InfluxDB and Grafana:
- What out-of-the-box solutions are available for real-time monitoring JMeter tests?
- What are the benefits of integrating InfluxDB and Grafana into the load testing stack?
- Which features are provided by Grafana?
- Demonstration of InfluxDB and Grafana using a practice web application
To view the webinar recording, go to:
https://www.rttsweb.com/jmeter-integration-webinar
Kubernetes & AI - Beauty and the Beast !?! @KCD Istanbul 2024Tobias Schneck
As AI technology is pushing into IT I was wondering myself, as an “infrastructure container kubernetes guy”, how get this fancy AI technology get managed from an infrastructure operational view? Is it possible to apply our lovely cloud native principals as well? What benefit’s both technologies could bring to each other?
Let me take this questions and provide you a short journey through existing deployment models and use cases for AI software. On practical examples, we discuss what cloud/on-premise strategy we may need for applying it to our own infrastructure to get it to work from an enterprise perspective. I want to give an overview about infrastructure requirements and technologies, what could be beneficial or limiting your AI use cases in an enterprise environment. An interactive Demo will give you some insides, what approaches I got already working for real.
4. It turns out that style matters in
programming for the same
reason that it matters in writing.
It makes for better reading.
Douglas Crockford
JavaScript: The Good Parts
7. Signal-to-noise ratio (often abbreviated SNR or
S/N) is a measure used in science and engineering
that compares the level of a desired signal to the
level of background noise.
Signal-to-noise ratio is sometimes used informally
to refer to the ratio of useful information to false or
irrelevant data in a conversation or exchange.
http://en.wikipedia.org/wiki/Signal_to_noise_ratio
8. To be, or not to be: that is the question:
Whether 'tis nobler in the mind to suffer
The slings and arrows of outrageous fortune,
Or to take arms against a sea of troubles,
And by opposing end them?
William Shakespeare
Hamlet
9. Continuing existence or cessation of
existence: those are the scenarios. Is it
more empowering mentally to work towards
an accommodation of the downsizings and
negative outcomes of adversarial
circumstance, or would it be a greater
enhancement of the bottom line to move
forwards to a challenge to our current
difficulties, and, by making a commitment
to opposition, to effect their demise?
Tom Burton
Long Words Bother Me
10. public class RecentlyUsedList
{
private List<string> items;
public RecentlyUsedList()
{
items = new List<string>();
}
public void Add(string newItem)
{
if (items.Contains(newItem))
{
int position = items.IndexOf(newItem);
string existingItem = items[position];
items.RemoveAt(position);
items.Insert(0, existingItem);
}
else
{
items.Insert(0, newItem);
}
}
public int Count
{
get
{
int size = items.Count;
return size;
}
}
public string this[int index]
{
get
{
int position = 0;
foreach (string item in items)
{
if (position == index)
return item;
++position;
}
throw new ArgumentOutOfRangeException();
}
}
}
11. public class RecentlyUsedList
{
private List<string> items;
public RecentlyUsedList()
{
items = new List<string>();
}
public void Add(string newItem)
{
if (items.Contains(newItem))
{
int position = items.IndexOf(newItem);
string existingItem = list[position];
items.RemoveAt(position);
items.Insert(0, existingItem);
}
else
{
items.Insert(0, newItem);
}
}
public int Count
{
get
{
int size = items.Count;
return size;
}
}
public string this[int index]
{
get
{
int position = 0;
foreach (string value in items)
{
if (position == index)
return value;
++position;
}
throw new ArgumentOutOfRangeException();
}
}
}
public class RecentlyUsedList
{
private List<string> items = new List<string>();
public void Add(string newItem)
{
items.Remove(newItem);
items.Add(newItem);
}
public int Count
{
get
{
return items.Count;
}
}
public string this[int index]
{
get
{
return items[Count - index - 1];
}
}
}
12.
13.
14. Comments
A delicate matter, requiring taste and judgement. I tend to err on the side of
eliminating comments, for several reasons. First, if the code is clear, and uses
good type names and variable names, it should explain itself. Second, comments
aren't checked by the compiler, so there is no guarantee they're right, especially
after the code is modified. A misleading comment can be very confusing. Third,
the issue of typography: comments clutter code.
Rob Pike, "Notes on Programming in C"
15. There is a famously bad comment style:
i=i+1; /* Add one to i */
and there are worse ways to do it:
/**********************************
* *
* Add one to i *
* *
**********************************/
i=i+1;
Don't laugh now, wait until you see it in real life.
Rob Pike, "Notes on Programming in C"
16. A common fallacy is to assume authors
of incomprehensible code will somehow
be able to express themselves lucidly
and clearly in comments.
Kevlin Henney
https://twitter.com/KevlinHenney/status/381021802941906944
19. To be, or not to be: that is the question:
Whether 'tis nobler in the mind to suffer
The slings and arrows of outrageous fortune,
Or to take arms against a sea of troubles,
And by opposing end them?
William Shakespeare
Hamlet
20. Continuing existence or cessation of
existence: those are the scenarios. Is it
more empowering mentally to work towards
an accommodation of the downsizings and
negative outcomes of adversarial
circumstance, or would it be a greater
enhancement of the bottom line to move
forwards to a challenge to our current
difficulties, and, by making a commitment
to opposition, to effect their demise?
Tom Burton
Long Words Bother Me
21. Continuing existence or cessation of existence:
those are the
more empowe
to work towa
accommodati
downsizings
outcomes of
circumstance
a greater enh
the bottom li
forwards to a
our current d
by making a
opposition, t
demise?
24. To answer the question "What is clean design?"
most succinctly: a clean design is one that
supports visual thinking so people can meet their
informational needs with a minimum of
conscious effort.
Daniel Higginbotham ∙ "Clean Up Your Mess — A Guide to Visual Design for Everyone ∙ http://www.visualmess.com/
25. You convey information by the way you arrange
a design's elements in relation to each other. This
information is understood immediately, if not
consciously, by the people viewing your designs.
Daniel Higginbotham ∙ "Clean Up Your Mess — A Guide to Visual Design for Everyone ∙ http://www.visualmess.com/
26. This is great if the visual relationships are
obvious and accurate, but if they're not, your
audience is going to get confused. They'll have to
examine your work carefully, going back and
forth between the different parts to make sure
they understand.
Daniel Higginbotham ∙ "Clean Up Your Mess — A Guide to Visual Design for Everyone ∙ http://www.visualmess.com/
27. public int howNotToLayoutAMethodHeader(int firstArgument,
String secondArgument)
public int ensureArgumentsAreAlignedLikeThis(
int firstArgument,
String secondArgument)
public int orEnsureArgumentsAreGroupedLikeThis(
int firstArgument, String secondArgument)
public int butNotAlignedLikeThis(int firstArgument,
String secondArgument)
28. int doNotFormat = likeThis(someArgumentOrExpression,
anotherArgumentOrExpression);
int insteadFormat =
somethingLikeThis(
someArgumentOrExpression,
anotherArgumentOrExpression);
int orFormat = somethingLikeThis(
someArgumentOrExpression,
anotherArgumentOrExpression);
29. int asItIs = unstable(someArgumentOrExpression,
anotherArgumentOrExpression);
int butThisIs =
stable(
someArgumentOrExpression,
anotherArgumentOrExpression);
int andThisIs = stable(
someArgumentOrExpression,
anotherArgumentOrExpression);
39. Agglutination is a process in linguistic morphology
derivation in which complex words are formed by
stringing together morphemes, each with a single
grammatical or semantic meaning. Languages that
use agglutination widely are called agglutinative
languages.
http://en.wikipedia.org/wiki/Agglutination
58. encapsulate
enclose (something) in or as if in a capsule.
express the essential feature of (someone or
something) succinctly.
provide an interface for (a piece of software or
hardware) to allow or simplify access for the
user.
The New Oxford Dictionary of English
59. An affordance is a quality of an
object, or an environment, which
allows an individual to perform an
action. For example, a knob affords
twisting, and perhaps pushing,
while a cord affords pulling.
http://en.wikipedia.org/wiki/Affordance
60. public class RecentlyUsedList
{
private List<string> items = new List<string>();
public List<string> Items
{
get
{
return items;
}
}
public void Add(string newItem)
{
if(newItem == null)
throw new ArgumentNullException();
items.Remove(newItem);
items.Insert(0, newItem);
}
...
}
61. public class RecentlyUsedList
{
private List<string> items = new List<string>();
public List<string> Items
{
get
{
return items;
}
}
public void Add(string newItem)
{
if(newItem == null)
throw new ArgumentNullException();
items.Remove(newItem);
items.Insert(0, newItem);
}
...
}
62. public class RecentlyUsedList
{
private List<string> items = new List<string>();
public List<string> Items
{
get
{
return items;
}
}
public void Add(string newItem)
{
if(newItem == null)
throw new ArgumentNullException();
items.Remove(newItem);
items.Insert(0, newItem);
}
...
}
var list = new RecentlyUsedList();
list.Add("Hello, World!");
Console.WriteLine(list.Items.Count);
list.Items.Add("Hello, World!");
Console.WriteLine(list.Items.Count);
list.Items.Add(null);
63. Don't ever invite a
vampire into your
house, you silly boy.
It renders you
powerless.
64. public class RecentlyUsedList
{
private IList<string> items = new List<string>();
public int Count
{
get
{
return items.Count;
}
}
public string this[int index]
{
get
{
return items[index];
}
}
public void Add(string newItem)
{
if(newItem == null)
throw new ArgumentNullException();
items.Remove(newItem);
items.Insert(0, newItem);
}
...
}
65. public class RecentlyUsedList
{
private IList<string> items = new List<string>();
public int Count
{
get
{
return items.Count;
}
}
public string this[int index]
{
get
{
return items[Count – index - 1];
}
}
public void Add(string newItem)
{
if(newItem == null)
throw new ArgumentNullException();
items.Remove(newItem);
items.Add(newItem);
}
...
}
73. public class Money implements ...
{
...
public int getUnits() ...
public int getHundredths() ...
public Currency getCurrency() ...
...
public void setUnits(int newUnits) ...
public void setHundredths(int newHundredths) ...
public void setCurrency(Currency newCurrency) ...
...
}
74. public final class Money implements ...
{
...
public int getUnits() ...
public int getHundredths() ...
public Currency getCurrency() ...
...
}
75. public final class Money implements ...
{
...
public int units() ...
public int hundredths() ...
public Currency currency() ...
...
}
76. When it is not
necessary to
change, it is
necessary not to
change.
Lucius Cary
79. Everybody knows that TDD stands for Test Driven
Development. However, people too often concentrate
on the words "Test" and "Development" and don't
consider what the word "Driven" really implies. For
tests to drive development they must do more than
just test that code performs its required functionality:
they must clearly express that required functionality
to the reader. That is, they must be clear specifications
of the required functionality. Tests that are not written
with their role as specifications in mind can be very
confusing to read.
Nat Pryce and Steve Freeman
"Are Your Tests Really Driving Your Development?"
80. public class RecentlyUsedList
{
...
public RecentlyUsedList() ...
public int Count
{
get...
}
public string this[int index]
{
get...
}
public void Add(string newItem) ...
...
}
82. So who should you be writing the tests
for? For the person trying to
understand your code.
Good tests act as documentation for
the code they are testing. They
describe how the code works. For each
usage scenario, the test(s):
Describe the context, starting point,
or preconditions that must be
satisfied
Illustrate how the software is
invoked
Describe the expected results or
postconditions to be verified
Different usage scenarios will have
slightly different versions of each of
these.
Gerard Meszaros
"Write Tests for People"
83. namespace RecentlyUsedList_spec
{
[TestFixture]
public class A_new_list
{
[Test] public void Is_empty()
}
[TestFixture]
public class An_empty_list
{
[Test] public void Retains_a_single_addition()
[Test] public void Retains_unique_additions_in_stack_order()
}
[TestFixture]
public class A_non_empty_list
{
[Test] public void Is_unchanged_when_head_item_is_readded()
[Test] public void Moves_non_head_item_to_head_when_it_is_readded()
}
[TestFixture]
public class Any_list
{
[Test] public void Rejects_addition_of_null_items()
}
}
84. namespace RecentlyUsedList_spec
{
[TestFixture]
public class A_new_list
{
[Test] public void Is_empty()
}
[TestFixture]
public class An_empty_list
{
[Test] public void Retains_a_single_addition()
[Test] public void Retains_unique_additions_in_stack_order()
}
[TestFixture]
public class A_non_empty_list
{
[Test] public void Is_unchanged_when_head_item_is_readded()
[Test] public void Moves_non_head_item_to_head_when_it_is_readded()
}
[TestFixture]
public class Any_list
{
[Test] public void Rejects_addition_of_null_items()
}
}
85. A test case should
be just that: it
should correspond
to a single case.