technology for reduce of mistakes - うっかりをなくす技術
TRANSCRIPT
Technology for reduce of mistakesid:karupaneura YAPC::Asia 2015 #yapcasiaD
Oops.. I forgot AC adaptor..
Thank you very very much!!!!
Hello, YAPC::Asia!!
About me
• Kenta SATO (id:karupanerura)
• Perl/XS/Swift/Kotlin/Java/Crystal/C99/etc..
• Gotanda.pm Author
• Senior Engineer at Mobile Factory, Inc.
• WebApp/iOS/Android/Operation/etc..
CPAN (PAUSE: KARUPA)
• Time::Strptime
• Geo::Hex::V3::XS
• Test::SharedObject
• Plack::App::Vhost
• etc..
YAPC::Asia with me
• 2011: LT (My first attend to YAPC::Asia)
• 2012: LT + Individual Sponsor
• 2013: 20min Talk + individual sponsor
• 2014: 40min Talk + individual sponsor + volunteer staff
• 2015: 60min Talk + individual sponsor + core staff
• 2016: ???
Summary of this talk
Summary of the talk
• About of human error. (human factors)
• How to reduce human error?
• The hint for reducing of human error factors
• by technology/technic
Agenda
1. Human Error
2. How to notice human error factors?
3. How to reduce factors by engineering?
4. Approaches by engineering
5. Conclusion
Human Error
We need safe code
• Don’t want to crash application
• Don’t want to mistake the code operation
• Don’t want to destroy data
• Don’t want to break code when modified
What is human error?
Human error ≒ mistake
Human error is …
• The word of human factors field
• David Meister defined:
• “a deviations from the requested performance by system.”
• source: “Human factors: theory and practice”
POINT: Human error is …
• In our context: operator = another developer
• It’s defined in a operator’s context
• Engineers create a system and operate it ourself.
• So we should think that a developer and a operator are different person.
POINT: Human error is …
• “System” means …
• a infrastructure
• a application
• a source code
• etc…
Why happen a human error?
Factor of human error
• grouping by factor:
• Human factor
• Management factor
• Environment factor
Human factors
• Direct factor:
• A carelessness
• A mistake
Approach for human factors• Control arousal level
• Pointing confirmation
• Accident prediction training
• NKY Training
Management factors
• Indirect factor:
• Not enough direction
• Not enough review
Approach for management factors• Work flow improvements
• Simplification of proces
• Code review
• Documentation
• Automation
Environment factors
• Indirect factor:
• Difficult to understand
• Complex ways
• Tend to overlook a mistake
• Tend to make mistakes
Approach for environment factors• Make it easy to understand
• Simple ways
• Tend to notice a mistake
• Prevent/Safe a mistake
CONCLUSION of this section
• Human error ≒ mistake
• Think in another developer's point of view
• Is it difficult to understand?
• Are there complex ways?
• Is it be tend to overlook a mistake?
Agenda
1. Human Error
2. How to notice human error factors?
3. How to reduce factors by engineering?
4. Approaches by engineering
5. Conclusion
How to notice mistake factors?
near-miss
• In Japanese “ヒヤリ・ハット”
• Accidents that cause no loss/injuries/damage
Heinrich's law
“that in a workplace, for every one major injury accident there are 29 accidents that cause minor injuries and 300 accidents that cause no injuries (what are often termed “incidents”), roughly a 1-30-300 proportioning.”
Heinrich's lawserious accident
slight accident
near-miss
frequency
POINT: Heinrich's law
A mistake factor makes many near-misses
Be careful near-miss!
• Tend to overlook
• because not loss/injuries/damages
• Resolving near-misses prevents incidents
How to find near-misses factors?
Collect the case of near-misses
How to collect the case of near-misses?
Github issue is awesome
• Tag is awesome
• CRITICAL/LITE/ARCH/CODE/etc..
• Engineer friendly
• Easy to link with code
Code review
• Get a operator points of view
• Find a factor of near-miss
• Create issue soon
• Analyze and fix it
CONCLUSION of this section
• Resolving near-misses prevents incidents
• Should collect the case of near-misses
• GitHub issue is good
• Code review is good approach
• for finding a factor of near-misses
Agenda
1. Human Error
2. How to notice human error factors?
3. How to reduce factors by engineering?
4. Approaches by engineering
5. Conclusion
How to reduce mistake factors
by engineering?
Environment factors can be reduced by engineering
How to reduce environment factors?
Approaches
• Easy to understand
• Simple ways
• Tend to notice a mistake
• Prevent/Safe a mistake
break..
Agenda
1. Human Error
2. How to notice human error factors?
3. How to reduce factors by engineering?
4. Approaches by engineering
5. Conclusion
Approachs by engineering
Easy to understand
Easy to understand
• Readable code
• Descriptive naming
• Code document/comment
• Less side effects
Readable code
• Read it!!!!!!!!!!!!!
Readable code
READ IT
SOON
Descriptive naming
帰れま10
Descriptive naming
Descriptive naming
Descriptive naming
Code document/comment
• This does know you(developer) only!
• ”Why this approach is used?"
• "Why this workaround is needed?"
• etc..
• But, Operator needs this information.
Less side effects
• No any side effects is best.
• But, we uses ...
• database
• view
• and ...
Less side effects
• Approach:
• (Don't use global variable)
• Shorten object lifecycle
• Immutable(Readonly) object/value
• Functional programming
Shorten object lifecycle
• Less status changes reduces side effects
• Object has statuses
• Make object in a minimum of scope
e.g. Sledge::Plugin::Stash
Immutable object/value
• Immutable object don't have any statuses
• It reduces side effects
• No logic depend on mutable status
• It makes many side effects in many cases
• Immutable object makes immutable status
Immutable object/value
• Immutable variable:
• Swift:let / Java:final / Kotlin:val / Scala:val
• Perl: (Library makes readonly value)
• Readonly.pm/Const.pm
• Internals::SvREADONLY
Immutable object/value
• Immutable object:
• Value object pattern
Functional programming
• This is one approach for that the status is closed in minimal scope
• The status is closed in function
• The side effect is close in monad
• (But, I don’t know too much this field.)
Simple ways
Simple ways
• Immutable object/value
• Shallow nested code
• Modularization
Shallow nested code
• Don't write deeply nested code
• Deeply nested code has many statuses
• It’s not simple
• Solution: structured programming
• Split code to other function
Modularization
• Operation of the procedure should be a simple.
• Operator need High-Level API
• Practice structured programming
Tend to notice a mistake
Tend to notice a mistake
• Type restriction/checking
• strict.pm / warnings.pm (Perl)
• Static code analysis (Perl::Critic/Perl::Lint)
• Optional
• Assertion
• Automated test
Type restriction
// Java
package org.yapcasia.app;
public class DB { public Prepare select (Query query) { // … }}
Type checking
## Perl
use Smart::Args;
sub select { args my $class => ‘ClassName’, my $sql => ‘FooDBI::Query’;
…}
What's the good point of type restrict/checking?• Checks type at compile-time or run-time
• Notices that type is incorrect
• When type is incorrect
• Operator probably made a mistake
strict.pm
## Perl (no strict.pm)
$foo = 1; # it pass
## Perl (enabled strict.pm)
use strict;$foo = 1; # compile time error
# my $foo = 1; # *MUST* declare `my` variable# $foo = 2; # can use declared variable *ONLY*
What's the good point of strict.pm?• Notices the typo at compile-time
• Difficult to use is a bad way in strict mode
• e.g.) soft reference
• SEE ALSO: perldoc strict
warnings.pm
## Perl (no warnings.pm)
my $answer = ‘3:’ + 2; # => 5 (!?)
## Perl (enabled warnings.pm)
use warnings;
my $answer = ‘3:’ + 2; # => 5 (!?)# WARN: Argument "3:" isn't numeric in addition (+) at …
What's the good point of warnings.pm?• Notices the incompatible implicit type
conversion at run-time
• and some warnings are available
• SEE ALSO: perldoc warnings
Static code analysis
• Finds popular mistakes.
• in Perl: Perl::Critic/Perl::Lint
• in JavaScript: ESLint/JSLint/JSHint/etc..
• in Java: FindBugs/etc..
• in Swift: (I’m needing it, but not found yet..)
Optional
// Swift
var foo : Int? = someNilableLogic()if let notNilFoo : Int = foo { // notNilFoo is not null}
println(“\(foo + 1)”) // it makes compile-time error
What's the good point of Optional• Ensures the safety of access to nullable value
• in compile-time
• not need to check null manually
• Maybe monad can also be used as well
• .. maybe :p
Assertion
/*** C ***/
int i = 1;i = add(i, 2);assert(i == 3); /* abort when `add` is broken */
What's the good point of Assertion• Prerequisites becomes clear
• Notices when the precondition is lost
• in run-time
• C++11: static_assert
• checks assertion at compile-time
Automated test
• No explanation needed :)
Prevent/Safe a mistake
Prevent/Safe a mistake
• defer, guard object, try-with-resources
• Max reqs per child
• Poka-yoke
defer
// Swift 2.0 (XXX: not checked yet)let fd = open(filename, O_RDONLY)defer { close(fd) }…
// Gofh, err := os.Open(filename)if err != nil { panic(err)}defer f.Close()
guard object
## Perl
use Guard;
my $sock = IO::Socket::INET->new(…);my $guard = guard { close($sock) };…
try-with-resources
## Java7
try (FileReader r = new FileReader(filename)) { // …}
What's the good point of defer, guard object?• Auto release the resources
• at appropriate timing
• in appropriate scope
• not need to release the resources manually
Max reqs par child
• “Limit on the number of requests that an individual child server will handle during its life” (Apache)
• When the memory leak occurs
• The problem is reduced
Poka-yoke
• In Japanese “ポカヨケ”
• The gimmick prevents mistake physically
• Example: Operator need shutdown a server
• When that the target server is used:
• Cannot shutdown
CONCLUSION of this section
• There is engineering approaches for
• notice/reduce/prevent near-misses
• run-time check is good
• compile-time check is very good
• Static typing language is awesome
Agenda
1. Human Error
2. How to notice human error factors?
3. How to reduce factors by engineering?
4. Approaches by engineering
5. Conclusion
CONCLUSION
Conclusion
• Think in another developer's point of view
• “Is it easy to understand?”, “Is it simple?”
• Resolving near-misses prevents incidents
• Should store the case of near-misses
• GitHub issue is good
Conclusion
• Good approach:
• Easy to understand
• Simple ways
• Tend to notice a mistake
• Prevent/Safe a mistake
TMTOWTDI :)
Let’s find the new safety approach!
Please vote me!
Thank you for listening
Any questions?