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.
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.
Seven Ineffective Coding Habits of Many ProgrammersKevlin Henney
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.
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.
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.
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.
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.
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.
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 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.
Seven Ineffective Coding Habits of Many ProgrammersKevlin Henney
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.
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.
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.
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.
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.
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.
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 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 8th Light University London (13th May 2016)
Do this, do that. Coding from assembler to shell scripting, from the mainstream languages of the last century to the mainstream languages now, is dominated by an imperative style. From how we teach variables — they vary, right? — to how we talk about databases, we are constantly looking at state as a thing to be changed and programming languages are structured in terms of the mechanics of change — assignment, loops and how code can be threaded (cautiously) with concurrency.
Functional programming, mark-up languages, schemas, persistent data structures and more are all based around a more declarative approach to code, where instead of reasoning in terms of who does what to whom and what the consequences are, relationships and uses are described, and the flow of execution follows from how functions, data and other structures are composed. This talk will look at the differences between imperative and declarative approaches, offering lessons, habits and techniques that are applicable from requirements through to code and tests in mainstream languages.
Presented at Dynabyte (13th April 2016)
I do not think it means what you think it means. What object means to many programmers is managers, views, controllers, getters and setters, megalithic frameworks, spaghetti inheritance, lots of mocks and large classes. But is this what object-oriented development is really about?
The original vision of objects was focused more on the problem domain than the solution domain. Objects were supposed to be small, properly encapsulated abstractions composed from other objects. Classes were a mechanism for expressing objects, not the editing black hole of the development process.
Think you know objects? This talk strips back the layers of habits, frameworks and legacy to cast objects in a new but old light.
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
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.
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.
Python Advanced – Building on the foundationKevlin Henney
This is a two-day course in Python programming aimed at professional programmers. The course material provided here is intended to be used by teachers of the language, but individual learners might find some of this useful as well.
The course assume the students already know Python, to the level taught in the Python Foundation course: http://www.slideshare.net/Kevlin/python-foundation-a-programmers-introduction-to-python-concepts-style)
The course is released under Creative Commons Attribution 4.0. Its primary location (along with the original PowerPoint) is at https://github.com/JonJagger/two-day-courses/tree/master/pa
Presented at GOTO Amsterdam (20th June 2014)
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 slightly more fluid, but having learnt from them more than expected.
Clean Coders Hate What Happens To Your Code When You Use These Enterprise Pro...Kevlin Henney
Presented at ACCU (24th April 2015)
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.
Keynote presented at DevWeek (24th March 2015)
Trees. Both beautiful and useful. But we’re not talking about the green, oxygen-providing ones. As abstract structures we see trees all over the place – file systems, class hierarchies, ordered data structures, etc. They are neat and tidy, nested and hierarchical – a simple way of organising things; a simple way of breaking large things down into small things.
The problem is, though, that there are many things – from modest fragments of code up to enterprise-wide IT systems – that do not comfortably fit into this way of looking at the world and organising it. Software architecture, design patterns, class decomposition, performance, unit tests... all of these cut across the strict hierarchy of trees. This keynote will look at what this means for how we think and design systems, whether large or small.
Presented at NDC London (5th December 2014)
Ralph Johnson defined architecture as "the decisions that you wish you could get right early in a project, but that you are not necessarily more likely to get them right than any other". Given our inability to tell the future how can we design effectively for it? Much project management thinking is based on the elimination of uncertainty, and advice on software architecture and guidance for future-proofing code often revolves around adding complexity to embrace uncertainty. In most cases, this is exactly the opposite path to the one that should be taken.
The talk looks at how uncertainty, lack of knowledge and options can be used to partition and structure the code in a system.
Presented at ACCU Conference (11th April 2014)
"When it is not necessary to change, it is necessary not to change" observed Lucius Cary, four centuries ago. He could well have been talking about program state (had such a concept existed). We have it by the bucket — by the megabucket, gigabucket and terabucket — and most code, designs and programming languages assume that program state is something that is changeable. But should it? Is this assumption always valid? Is state change as necessary as its widespread use might suggest?
Immutability is a cornerstone of pure functional programming, and is often seen to be exclusively associated with it, but immutability and other restrictions on state mutability are more widely applicable, and certainly not the sole preserve of functional languages. It is a necessary practice in languages with reference-based semantics and in concurrent environments, for example. Without it, code becomes difficult to reason about (oh...) or chock full of locks and deadlocks (ah...). This loss of simplicity may seem familiar.
This talk looks at the consequences, benefits and implications of programming in an immutable or less mutable style, including techniques both large and small that can be applied in mainstream languages and existing systems.
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 8th Light University London (13th May 2016)
Do this, do that. Coding from assembler to shell scripting, from the mainstream languages of the last century to the mainstream languages now, is dominated by an imperative style. From how we teach variables — they vary, right? — to how we talk about databases, we are constantly looking at state as a thing to be changed and programming languages are structured in terms of the mechanics of change — assignment, loops and how code can be threaded (cautiously) with concurrency.
Functional programming, mark-up languages, schemas, persistent data structures and more are all based around a more declarative approach to code, where instead of reasoning in terms of who does what to whom and what the consequences are, relationships and uses are described, and the flow of execution follows from how functions, data and other structures are composed. This talk will look at the differences between imperative and declarative approaches, offering lessons, habits and techniques that are applicable from requirements through to code and tests in mainstream languages.
Presented at Dynabyte (13th April 2016)
I do not think it means what you think it means. What object means to many programmers is managers, views, controllers, getters and setters, megalithic frameworks, spaghetti inheritance, lots of mocks and large classes. But is this what object-oriented development is really about?
The original vision of objects was focused more on the problem domain than the solution domain. Objects were supposed to be small, properly encapsulated abstractions composed from other objects. Classes were a mechanism for expressing objects, not the editing black hole of the development process.
Think you know objects? This talk strips back the layers of habits, frameworks and legacy to cast objects in a new but old light.
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
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.
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.
Python Advanced – Building on the foundationKevlin Henney
This is a two-day course in Python programming aimed at professional programmers. The course material provided here is intended to be used by teachers of the language, but individual learners might find some of this useful as well.
The course assume the students already know Python, to the level taught in the Python Foundation course: http://www.slideshare.net/Kevlin/python-foundation-a-programmers-introduction-to-python-concepts-style)
The course is released under Creative Commons Attribution 4.0. Its primary location (along with the original PowerPoint) is at https://github.com/JonJagger/two-day-courses/tree/master/pa
Presented at GOTO Amsterdam (20th June 2014)
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 slightly more fluid, but having learnt from them more than expected.
Clean Coders Hate What Happens To Your Code When You Use These Enterprise Pro...Kevlin Henney
Presented at ACCU (24th April 2015)
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.
Keynote presented at DevWeek (24th March 2015)
Trees. Both beautiful and useful. But we’re not talking about the green, oxygen-providing ones. As abstract structures we see trees all over the place – file systems, class hierarchies, ordered data structures, etc. They are neat and tidy, nested and hierarchical – a simple way of organising things; a simple way of breaking large things down into small things.
The problem is, though, that there are many things – from modest fragments of code up to enterprise-wide IT systems – that do not comfortably fit into this way of looking at the world and organising it. Software architecture, design patterns, class decomposition, performance, unit tests... all of these cut across the strict hierarchy of trees. This keynote will look at what this means for how we think and design systems, whether large or small.
Presented at NDC London (5th December 2014)
Ralph Johnson defined architecture as "the decisions that you wish you could get right early in a project, but that you are not necessarily more likely to get them right than any other". Given our inability to tell the future how can we design effectively for it? Much project management thinking is based on the elimination of uncertainty, and advice on software architecture and guidance for future-proofing code often revolves around adding complexity to embrace uncertainty. In most cases, this is exactly the opposite path to the one that should be taken.
The talk looks at how uncertainty, lack of knowledge and options can be used to partition and structure the code in a system.
Presented at ACCU Conference (11th April 2014)
"When it is not necessary to change, it is necessary not to change" observed Lucius Cary, four centuries ago. He could well have been talking about program state (had such a concept existed). We have it by the bucket — by the megabucket, gigabucket and terabucket — and most code, designs and programming languages assume that program state is something that is changeable. But should it? Is this assumption always valid? Is state change as necessary as its widespread use might suggest?
Immutability is a cornerstone of pure functional programming, and is often seen to be exclusively associated with it, but immutability and other restrictions on state mutability are more widely applicable, and certainly not the sole preserve of functional languages. It is a necessary practice in languages with reference-based semantics and in concurrent environments, for example. Without it, code becomes difficult to reason about (oh...) or chock full of locks and deadlocks (ah...). This loss of simplicity may seem familiar.
This talk looks at the consequences, benefits and implications of programming in an immutable or less mutable style, including techniques both large and small that can be applied in mainstream languages and existing systems.
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.
this is the first of a series of three webinars I created in 2009. This is focus on general aspects of becoming more creative and turning any workplace into a Cre8ng Community
(Subtitle — User Experience: an Agony in Eight Fits)
Talk given by Chris Atherton at Technical Communication UK, 22nd September 2010.
The idea of this presentation was to introduce some findings from experimental psychology that might influence user experience design. Also, it was fun to see how riled up people can get about shower control design ... :)
Section 8 Programming Style and Your Brain: Douglas Crockfordjaxconf
Computer programs are the most complicated things that humans make. They must be perfect, which is hard for us because we are not perfect. Programming is thought to be a "head" activity, but there is a lot of "gut" involved. Indeed, it may be the gut that gives us the insight necessary for solving hard problems. But gut messes us up when it come to matters of style.
The systems in our brains that make us vulnerable to advertising and propaganda also influence our programming styles. This talk looks systematically at the development of a programming style that specifically improves the reliability of programs. The examples are given in JavaScript, a language with an uncommonly large number of bad parts, but the principles are applicable to all languages.
The majority of cyber attacks against organisations and peoples start with general data about their targets, or very specific data, about one individual who can be used as an access portal to everyone, and everything! Sadly, the majority of attacks appear to be founded on known and published, or simple/very weak passwords that here easy to guess or crack with modest tools.
“I think we can safely assume; ‘Joe Public’ has little knowledge of cyber-security and even less inclination to engage in good security practices. And so, we have a ubiquitous security risk at every level of society with no hope of curing the problem through education and training”
This is compounded by vast libraries of professional papers, web sites, and industry studies that proffer a somewhat confusing range of guidelines and advice largely invisible to, and unhelpful for, the lay population. Probably the ultimate long term solution, in the face of an enemy that is becoming more sophisticated, powerful, and determined by the day, is the full automation through built in biometrics based on face, hand, finger, voice, typing patterns et al. plus a PIN and simple password/’n' factor authentication.
For sure we need an industry based fix; and probably in the form of ‘security as a service’. In the meantime, this presentation addresses what it takes to create ‘fit-for-purpose’ passwords at a device level and on up through Cloud Working. The techniques and guidelines give an assured security spanning trivial documentation through to financial services and state secrets applicable for 2019/20/21. For 2021/22/23 it would be prudent to reassess the advance in attack technologies and techniques, and the change in the success statistics of the Dark Side. It is quite likely that passwords may need strengthening by the addition of additional characters in some cases.
Links to associated/related/earlier slide sets are also provided.
A Timeless Way of Communicating: Alexandrian Pattern LanguagesJoshua Kerievsky
If you pick up the masterpiece, "A Pattern Language", by Christopher Alexander et. al, you will discover a book filled with engaging photographs, hand-drawn sketches, big bold, hard-to-miss text, memorable stories and scholarly notes for the academically minded. One can quickly "surf" this book by focusing only on pattern titles, images and headlines or one can dive deep into the book by reading the detailed text of each pattern. In short, A Pattern Language uses a timeless way of communicating, a form that engages people and provides numerous pathways for accessing the knowledge. As authors of software-related pattern languages, we must understand what it takes to make our own works endure. In this talk, we will analyze the form and content of real-world software patterns/pattern languages, looking for what makes them succeed or fail at engaging the reader and providing knowledge pathways. If you are interested in crafting great pattern languages,this talk will help you discover some essential ingredients.
The system metaphor is one of the trickier parts of XP (Extreme Programming). This presentation is from a tutorial taught at several of the early agile conferences, and includes material supporting the exercises. CC-BY-SA
Let us begin with mentioning that this article is completely non-serious. New Year is coming, holidays are almost there and there is no reason to do anything deliberate. That is why we decided to write an article about, suddenly, statistics.
How To Write Like a Human - by Claire DawsonZeus Jones
There’s a lot of angst out there about writing. So, here’s a primer on how to tackle the job of writing when you feel like you just don’t know what to say (or when you feel like you do know what to say, but you have no idea how to say it).
Similar to Seven Ineffective Coding Habits of Many Programmers (20)
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.
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.
Large Language Models and the End of ProgrammingMatt Welsh
Talk by Matt Welsh at Craft Conference 2024 on the impact that Large Language Models will have on the future of software development. In this talk, I discuss the ways in which LLMs will impact the software industry, from replacing human software developers with AI, to replacing conventional software with models that perform reasoning, computation, and problem-solving.
Check out the webinar slides to learn more about how XfilesPro transforms Salesforce document management by leveraging its world-class applications. For more details, please connect with sales@xfilespro.com
If you want to watch the on-demand webinar, please click here: https://www.xfilespro.com/webinars/salesforce-document-management-2-0-smarter-faster-better/
Listen to the keynote address and hear about the latest developments from Rachana Ananthakrishnan and Ian Foster who review the updates to the Globus Platform and Service, and the relevance of Globus to the scientific community as an automation platform to accelerate scientific discovery.
Prosigns: Transforming Business with Tailored Technology SolutionsProsigns
Unlocking Business Potential: Tailored Technology Solutions by Prosigns
Discover how Prosigns, a leading technology solutions provider, partners with businesses to drive innovation and success. Our presentation showcases our comprehensive range of services, including custom software development, web and mobile app development, AI & ML solutions, blockchain integration, DevOps services, and Microsoft Dynamics 365 support.
Custom Software Development: Prosigns specializes in creating bespoke software solutions that cater to your unique business needs. Our team of experts works closely with you to understand your requirements and deliver tailor-made software that enhances efficiency and drives growth.
Web and Mobile App Development: From responsive websites to intuitive mobile applications, Prosigns develops cutting-edge solutions that engage users and deliver seamless experiences across devices.
AI & ML Solutions: Harnessing the power of Artificial Intelligence and Machine Learning, Prosigns provides smart solutions that automate processes, provide valuable insights, and drive informed decision-making.
Blockchain Integration: Prosigns offers comprehensive blockchain solutions, including development, integration, and consulting services, enabling businesses to leverage blockchain technology for enhanced security, transparency, and efficiency.
DevOps Services: Prosigns' DevOps services streamline development and operations processes, ensuring faster and more reliable software delivery through automation and continuous integration.
Microsoft Dynamics 365 Support: Prosigns provides comprehensive support and maintenance services for Microsoft Dynamics 365, ensuring your system is always up-to-date, secure, and running smoothly.
Learn how our collaborative approach and dedication to excellence help businesses achieve their goals and stay ahead in today's digital landscape. From concept to deployment, Prosigns is your trusted partner for transforming ideas into reality and unlocking the full potential of your business.
Join us on a journey of innovation and growth. Let's partner for success with Prosigns.
We describe the deployment and use of Globus Compute for remote computation. This content is aimed at researchers who wish to compute on remote resources using a unified programming interface, as well as system administrators who will deploy and operate Globus Compute services on their research computing infrastructure.
May Marketo Masterclass, London MUG May 22 2024.pdfAdele Miller
Can't make Adobe Summit in Vegas? No sweat because the EMEA Marketo Engage Champions are coming to London to share their Summit sessions, insights and more!
This is a MUG with a twist you don't want to miss.
Code reviews are vital for ensuring good code quality. They serve as one of our last lines of defense against bugs and subpar code reaching production.
Yet, they often turn into annoying tasks riddled with frustration, hostility, unclear feedback and lack of standards. How can we improve this crucial process?
In this session we will cover:
- The Art of Effective Code Reviews
- Streamlining the Review Process
- Elevating Reviews with Automated Tools
By the end of this presentation, you'll have the knowledge on how to organize and improve your code review proces
Understanding Globus Data Transfers with NetSageGlobus
NetSage is an open privacy-aware network measurement, analysis, and visualization service designed to help end-users visualize and reason about large data transfers. NetSage traditionally has used a combination of passive measurements, including SNMP and flow data, as well as active measurements, mainly perfSONAR, to provide longitudinal network performance data visualization. It has been deployed by dozens of networks world wide, and is supported domestically by the Engagement and Performance Operations Center (EPOC), NSF #2328479. We have recently expanded the NetSage data sources to include logs for Globus data transfers, following the same privacy-preserving approach as for Flow data. Using the logs for the Texas Advanced Computing Center (TACC) as an example, this talk will walk through several different example use cases that NetSage can answer, including: Who is using Globus to share data with my institution, and what kind of performance are they able to achieve? How many transfers has Globus supported for us? Which sites are we sharing the most data with, and how is that changing over time? How is my site using Globus to move data internally, and what kind of performance do we see for those transfers? What percentage of data transfers at my institution used Globus, and how did the overall data transfer performance compare to the Globus users?
Quarkus Hidden and Forbidden ExtensionsMax Andersen
Quarkus has a vast extension ecosystem and is known for its subsonic and subatomic feature set. Some of these features are not as well known, and some extensions are less talked about, but that does not make them less interesting - quite the opposite.
Come join this talk to see some tips and tricks for using Quarkus and some of the lesser known features, extensions and development techniques.
A Study of Variable-Role-based Feature Enrichment in Neural Models of CodeAftab Hussain
Understanding variable roles in code has been found to be helpful by students
in learning programming -- could variable roles help deep neural models in
performing coding tasks? We do an exploratory study.
- These are slides of the talk given at InteNSE'23: The 1st International Workshop on Interpretability and Robustness in Neural Software Engineering, co-located with the 45th International Conference on Software Engineering, ICSE 2023, Melbourne Australia
First Steps with Globus Compute Multi-User EndpointsGlobus
In this presentation we will share our experiences around getting started with the Globus Compute multi-user endpoint. Working with the Pharmacology group at the University of Auckland, we have previously written an application using Globus Compute that can offload computationally expensive steps in the researcher's workflows, which they wish to manage from their familiar Windows environments, onto the NeSI (New Zealand eScience Infrastructure) cluster. Some of the challenges we have encountered were that each researcher had to set up and manage their own single-user globus compute endpoint and that the workloads had varying resource requirements (CPUs, memory and wall time) between different runs. We hope that the multi-user endpoint will help to address these challenges and share an update on our progress here.
How Recreation Management Software Can Streamline Your Operations.pptxwottaspaceseo
Recreation management software streamlines operations by automating key tasks such as scheduling, registration, and payment processing, reducing manual workload and errors. It provides centralized management of facilities, classes, and events, ensuring efficient resource allocation and facility usage. The software offers user-friendly online portals for easy access to bookings and program information, enhancing customer experience. Real-time reporting and data analytics deliver insights into attendance and preferences, aiding in strategic decision-making. Additionally, effective communication tools keep participants and staff informed with timely updates. Overall, recreation management software enhances efficiency, improves service delivery, and boosts customer satisfaction.
OpenMetadata Community Meeting - 5th June 2024OpenMetadata
The OpenMetadata Community Meeting was held on June 5th, 2024. In this meeting, we discussed about the data quality capabilities that are integrated with the Incident Manager, providing a complete solution to handle your data observability needs. Watch the end-to-end demo of the data quality features.
* How to run your own data quality framework
* What is the performance impact of running data quality frameworks
* How to run the test cases in your own ETL pipelines
* How the Incident Manager is integrated
* Get notified with alerts when test cases fail
Watch the meeting recording here - https://www.youtube.com/watch?v=UbNOje0kf6E
Essentials of Automations: The Art of Triggers and Actions in FMESafe Software
In this second installment of our Essentials of Automations webinar series, we’ll explore the landscape of triggers and actions, guiding you through the nuances of authoring and adapting workspaces for seamless automations. Gain an understanding of the full spectrum of triggers and actions available in FME, empowering you to enhance your workspaces for efficient automation.
We’ll kick things off by showcasing the most commonly used event-based triggers, introducing you to various automation workflows like manual triggers, schedules, directory watchers, and more. Plus, see how these elements play out in real scenarios.
Whether you’re tweaking your current setup or building from the ground up, this session will arm you with the tools and insights needed to transform your FME usage into a powerhouse of productivity. Join us to discover effective strategies that simplify complex processes, enhancing your productivity and transforming your data management practices with FME. Let’s turn complexity into clarity and make your workspaces work wonders!
GraphSummit Paris - The art of the possible with Graph TechnologyNeo4j
Sudhir Hasbe, Chief Product Officer, Neo4j
Join us as we explore breakthrough innovations enabled by interconnected data and AI. Discover firsthand how organizations use relationships in data to uncover contextual insights and solve our most pressing challenges – from optimizing supply chains, detecting fraud, and improving customer experiences to accelerating drug discoveries.
5. code, noun
a set of instructions for a computer
a computer program, or a portion thereof
a system of words, figures or symbols used to
represent others, especially for the purposes of
secrecy
a set of conventions or principles governing
behaviour or activity in a particular domain
Concise Oxford English Dictionary ∙ Oxford English Dictionary ∙ Merriam-Webster's Collegiate Dictionary
6. habit, noun
a settled or regular tendency or practice
an acquired mode of behaviour that has become
nearly or completely involuntary
bodily condition or constitution
a costume characteristic of a calling, rank, or
function
Concise Oxford English Dictionary ∙ Oxford English Dictionary ∙ Merriam-Webster's Collegiate Dictionary
16. 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
17. 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
18. 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
19. function leftpad (str, len, ch) {
str = String(str);
var i = -1;
if (!ch && ch !== 0) ch = ' ';
len = len - str.length;
while (++i < len) {
str = ch + str;
}
return str;
}
21. function leftpad(content, length, pad) {
content = String(content)
pad = String(pad || pad === 0 ? pad : ' ')[0]
var left = Math.max(length - content.length, 0)
return pad.repeat(left) + content
}
22.
23. var cache = [
'',
' ',
' ',
' ',
' ',
' ',
' ',
' ',
' ',
' '
];
function leftPad (str, len, ch) {
// convert `str` to `string`
str = str + '';
// `len` is the `pad`'s length now
len = len - str.length;
// doesn't need to pad
if (len <= 0) return str;
// `ch` defaults to `' '`
if (!ch && ch !== 0) ch = ' ';
// convert `ch` to `string`
ch = ch + '';
// cache common use cases
if (ch === ' ' && len < 10) return cache[len] + str;
// `pad` starts with an empty string
var pad = '';
// loop
while (true) {
// add `ch` to `pad` if `len` is odd
if (len & 1) pad += ch;
// divide `len` by 2, ditch the remainder
len >>= 1;
// "double" the `ch` so this operation count grows logarithmically on `len`
// each time `ch` is "doubled", the `len` would need to be "doubled" too
// similar to finding a value in binary search tree, hence O(log(n))
if (len) ch += ch;
// `len` is 0, exit the loop
else break;
}
// pad `str`!
return pad + str;
}
24.
25.
26. 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"
27. 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"
28. 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
31. 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
32. 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
33. 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?
36. 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/
37. 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/
38. 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/
39. 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)
40. int doNotFormat = likeThis(someArgumentOrExpression,
anotherArgumentOrExpression);
int insteadFormat =
somethingLikeThis(
someArgumentOrExpression,
anotherArgumentOrExpression);
int orFormat = somethingLikeThis(
someArgumentOrExpression,
anotherArgumentOrExpression);
41. int asItIs = unstable(someArgumentOrExpression,
anotherArgumentOrExpression);
int butThisIs =
stable(
someArgumentOrExpression,
anotherArgumentOrExpression);
int andThisIs = stable(
someArgumentOrExpression,
anotherArgumentOrExpression);
51. 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
56. People will be using the
words you choose in their
conversation for the next 20
years. You want to be sure
you do it right.
Unfortunately, many people
get all formal [...]. Just calling
it what it is isn't enough.
59. They have to tack on a
flowery, computer science-y,
impressive sounding, but
ultimately meaningless word,
like Object, Thing,
Component, Part, Manager,
Entity, or Item.
77. Don't ever invite a
vampire into your
house, you silly boy.
It renders you
powerless.
78. public class BankAccount
{
...
public decimal Balance
{
get ...
}
public void Deposit(decimal amount) ...
public void Withdraw(decimal amount) ...
...
}
85. 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) ...
...
}
86. public final class Money implements ...
{
...
public int getUnits() ...
public int getHundredths() ...
public Currency getCurrency() ...
...
}
93. 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?"
96. public class Stack<T>
{
private
public Stack()
public void push(T newTop)
public void pop()
public int depth()
public T top()
}
97. public class StackTests
{
@Test
public void testConstructor()
@Test
public void testPush()
@Test
public void testPop()
@Test
public void testDepth()
@Test
public void testTop()
}
98. public class StackTests
{
@Test
public void constructor()
@Test
public void push()
@Test
public void pop()
@Test
public void depth()
@Test
public void top()
}
100. public class Stack_spec
{
public static class A_new_stack
{
@Test
public void is_empty()
}
public static class An_empty_stack
{
@Test()
public void throws_when_queried_for_its_top_item()
@Test()
public void throws_when_popped()
@Test
public void acquires_depth_by_retaining_a_pushed_item_as_its_top()
}
public static class A_non_empty_stack
{
@Test
public void becomes_deeper_by_retaining_a_pushed_item_as_its_top()
@Test
public void on_popping_reveals_tops_in_reverse_order_of_pushing()
}
}
101. public class
Stack_spec
{
public static class
A_new_stack
{
@Test
public void is_empty()
}
public static class
An_empty_stack
{
@Test()
public void throws_when_queried_for_its_top_item()
@Test()
public void throws_when_popped()
@Test
public void acquires_depth_by_retaining_a_pushed_item_as_its_top()
}
public static class
A_non_empty_stack
{
@Test
public void becomes_deeper_by_retaining_a_pushed_item_as_its_top()
@Test
public void on_popping_reveals_tops_in_reverse_order_of_pushing()
}
}
102. public class
Stack_spec
{
public static class
A_new_stack
{
@Test
public void is_empty()
}
public static class
An_empty_stack
{
@Test()
public void throws_when_queried_for_its_top_item()
@Test()
public void throws_when_popped()
@Test
public void acquires_depth_by_retaining_a_pushed_item_as_its_top()
}
public static class
A_non_empty_stack
{
@Test
public void becomes_deeper_by_retaining_a_pushed_item_as_its_top()
@Test
public void on_popping_reveals_tops_in_reverse_order_of_pushing()
}
}
103. function leftpad (str, len, ch) {
str = String(str);
var i = -1;
if (!ch && ch !== 0) ch = ' ';
len = len - str.length;
while (++i < len) {
str = ch + str;
}
return str;
}
104. function leftpad(content, length, pad) {
content = String(content)
pad = String(pad || pad === 0 ? pad : ' ')[0]
var left = Math.max(length - content.length, 0)
return pad.repeat(left) + content
}
106. function assert(condition) {
if(!condition)
throw { name: "AssertionError", message: "assertion failed" }
}
function testPasses(toTry) {
try {
toTry()
return true
} catch (failure) {
return false
}
}
function report(testName, passed) {
document.write(testName.fontcolor(passed ? "green" : "red") + "<br>")
}
function test(testCases) {
for (var testName in testCases)
if (testCases.hasOwnProperty(testName))
report(testName, testPasses(testCases[testName]))
}
107. test({
"Padding an empty string to a length of 0 results in an empty string":
() => assert(leftpad("", 0, "X") === ""),
"Padding a non-empty string to a shorter length results in the same string":
() => assert(leftpad("foobar", 3, "X") === "foobar"),
"Padding a non-empty string to a negative length results in the same string":
() => assert(leftpad("foobar", -3, "X") === "foobar"),
"Padding a non-empty string to its length results in the same string":
() => assert(leftpad("foobar", 6, "X") === "foobar"),
"Padding to a longer length with a single character fills to the left":
() => assert(leftpad("foobar", 8, "X") === "XXfoobar"),
"Padding to a longer length with surplus characters fills using only first":
() => assert(leftpad("foobar", 10, "XY") === "XXXXfoobar"),
"Padding to a longer length with an empty string fills with space":
() => assert(leftpad("foobar", 8, "") === " foobar"),
"Padding to a longer length with no specified fill fills with space":
() => assert(leftpad("foobar", 9) === " foobar"),
"Padding to a longer length with integer 0 fills with 0":
() => assert(leftpad("foobar", 7, 0) === "0foobar"),
"Padding to a longer length with single-digit integer fills with digit":
() => assert(leftpad("foobar", 10, 1) === "1111foobar"),
"Padding to a longer length with multiple-digit integer fills with first digit":
() => assert(leftpad("foobar", 10, 42) === "4444foobar"),
"Padding to a longer length with negative integer fills with -":
() => assert(leftpad("foobar", 8, -42) === "--foobar"),
"Padding a non-string uses string representation":
() => assert(leftpad(4.2, 5, 0) === "004.2")
})
108. Padding an empty string to a length of 0 results in an empty string
Padding a non-empty string to a shorter length results in the same string
Padding a non-empty string to a negative length results in the same string
Padding a non-empty string to its length results in the same string
Padding to a longer length with a single character fills to the left
Padding to a longer length with surplus characters fills using only first
Padding to a longer length with an empty string fills with space
Padding to a longer length with no specified fill fills with space
Padding to a longer length with integer 0 fills with 0
Padding to a longer length with single-digit integer fills with digit
Padding to a longer length with multiple-digit integer fills with first digit
Padding to a longer length with negative integer fills with -
Padding a non-string uses string representation
109. Padding an empty string to a length of 0 results in an empty string
Padding a non-empty string to a shorter length results in the same string
Padding a non-empty string to a negative length results in the same string
Padding a non-empty string to its length results in the same string
Padding to a longer length with a single character fills to the left
Padding to a longer length with surplus characters fills using only first
Padding to a longer length with an empty string fills with space
Padding to a longer length with no specified fill fills with space
Padding to a longer length with integer 0 fills with 0
Padding to a longer length with single-digit integer fills with digit
Padding to a longer length with multiple-digit integer fills with first digit
Padding to a longer length with negative integer fills with -
Padding a non-string uses string representation
110. A test case should
be just that: it
should correspond
to a single case.
111. As a
I want
So that
programmer
???
I can spend less time
determining the meaning
of code and more time
coding meaningfully
112. As a
I want
So that
programmer
code to communicate
directly and with intent
I can spend less time
determining the meaning
of code and more time
coding meaningfully