YAPC::Asia 2015 http://yapcasia.org/2015/talk/show/523b9508-0d77-11e5-8174-67dc7d574c3a (Please review and teach me my English.)

1. Technology
for
reduce of mistakes
id:karupaneura
YAPC::Asia 2015 #yapcasiaD

2. Oops.. I forgot AC adaptor..

3. Thank you very very much!!!!

4. Hello, YAPC::Asia!!

5. 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..

6. CPAN (PAUSE: KARUPA)
• Time::Strptime
• Geo::Hex::V3::XS
• Test::SharedObject
• Plack::App::Vhost
• etc..

7. Gotanda.pm #6
• at 9/17(Tue) GaiaX Inc.
• Join us!
• http://gotanda.pm.org/

8. 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: ???

9. Summary of this talk

10. 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

11. Agenda
1. Human Error
2. How to notice human error factors?
3. How to reduce factors by engineering?
4. Approaches by engineering
5. Conclusion

12. Human Error

13. 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

14. What is human error?

15. Human error ≒ mistake

16. 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”

17. 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.

18. POINT: Human error is …
• “System” means …
• a infrastructure
• a application
• a source code
• etc…

19. Why happen a human error?

20. Factor of human error
• grouping by factor:
• Human factor
• Management factor
• Environment factor

21. Human factors
• Direct factor:
• A carelessness
• A mistake

22. Approach for
human factors
• Control arousal level
• Pointing confirmation
• Accident prediction training
• NKY Training

23. Management factors
• Indirect factor:
• Not enough direction
• Not enough review

24. Approach for
management factors
• Work flow improvements
• Simplification of proces
• Code review
• Documentation
• Automation

25. Environment factors
• Indirect factor:
• Difficult to understand
• Complex ways
• Tend to overlook a mistake
• Tend to make mistakes

26. Approach for
environment factors
• Make it easy to understand
• Simple ways
• Tend to notice a mistake
• Prevent/Safe a mistake

27. 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?

28. Agenda
1. Human Error
2. How to notice human error factors?
3. How to reduce factors by engineering?
4. Approaches by engineering
5. Conclusion

29. How to notice
mistake factors?

30. near-miss
• In Japanese “ヒヤリ・ハット”
• Accidents that cause no loss/injuries/damage

31. 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.”

32. Heinrich's law
serious accident
slight accident
near-miss
frequency

33. POINT: Heinrich's law
A mistake factor makes many near-misses

34. Be careful near-miss!
• Tend to overlook
• because not loss/injuries/damages
• Resolving near-misses prevents incidents

35. How to find
near-misses factors?

36. Collect
the case of near-misses

37. How to collect
the case of near-misses?

39. Github issue is awesome
• Tag is awesome
• CRITICAL/LITE/ARCH/CODE/etc..
• Engineer friendly
• Easy to link with code

40. Code review
• Get a operator points of view
• Find a factor of near-miss
• Create issue soon
• Analyze and fix it

41. 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

42. Agenda
1. Human Error
2. How to notice human error factors?
3. How to reduce factors by engineering?
4. Approaches by engineering
5. Conclusion

43. How to reduce
mistake factors
by engineering?

44. Environment factors
can be reduced
by engineering

45. How to reduce
environment factors?

46. Approaches
• Easy to understand
• Simple ways
• Tend to notice a mistake
• Prevent/Safe a mistake

47. break..

48. Agenda
1. Human Error
2. How to notice human error factors?
3. How to reduce factors by engineering?
4. Approaches by engineering
5. Conclusion

49. Approachs by engineering

50. Easy to understand

51. Easy to understand
• Readable code
• Descriptive naming
• Code document/comment
• Less side effects

52. Readable code
• Read it!!!!!!!!!!!!!

53. Readable code
READ
IT
SOON

54. Descriptive naming
帰れま10

55. Descriptive naming

56. Descriptive naming

57. Descriptive naming

58. 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.

59. Less side effects
• No any side effects is best.
• But, we uses ...
• database
• view
• and ...

60. Less side effects
• Approach:
• (Don't use global variable)
• Shorten object lifecycle
• Immutable(Readonly) object/value
• Functional programming

61. Shorten object lifecycle
• Less status changes reduces side effects
• Object has statuses
• Make object in a minimum of scope

62. e.g. Sledge::Plugin::Stash

63. 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

64. Immutable object/value
• Immutable variable:
• Swift:let / Java:final / Kotlin:val / Scala:val
• Perl: (Library makes readonly value)
• Readonly.pm/Const.pm
• Internals::SvREADONLY

65. Immutable object/value
• Immutable object:
• Value object pattern

66. 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.)

67. Simple ways

68. Simple ways
• Immutable object/value
• Shallow nested code
• Modularization

69. 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

70. Modularization
• Operation of the procedure should be a
simple.
• Operator need High-Level API
• Practice structured programming

71. Tend to notice a mistake

72. Tend to notice a mistake
• Type restriction/checking
• strict.pm / warnings.pm (Perl)
• Static code analysis (Perl::Critic/Perl::Lint)
• Optional
• Assertion
• Automated test

73. Type restriction
// Java
package org.yapcasia.app;
public class DB {
public Prepare select (Query query) {
// …
}
}

74. Type checking
## Perl
use Smart::Args;
sub select {
args my $class => ‘ClassName’,
my $sql => ‘FooDBI::Query’;
…
}

75. 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

76. 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*

77. 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

78. 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 …

79. 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

80. 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..)

81. Optional
// Swift
var foo : Int? = someNilableLogic()
if let notNilFoo : Int = foo {
// notNilFoo is not null
}
println(“(foo + 1)”) // it makes compile-time error

82. 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

83. Assertion
/*** C ***/
int i = 1;
i = add(i, 2);
assert(i == 3); /* abort when `add` is broken */

84. 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

85. Automated test
• No explanation needed :)

86. Prevent/Safe a mistake

87. Prevent/Safe a mistake
• defer, guard object, try-with-resources
• Max reqs per child
• Poka-yoke

88. defer
// Swift 2.0 (XXX: not checked yet)
let fd = open(filename, O_RDONLY)
defer { close(fd) }
…
// Go
fh, err := os.Open(filename)
if err != nil {
panic(err)
}
defer f.Close()

89. guard object
## Perl
use Guard;
my $sock = IO::Socket::INET->new(…);
my $guard = guard { close($sock) };
…

90. try-with-resources
## Java7
try (FileReader r = new FileReader(filename)) {
// …
}

91. 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

92. 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

93. Poka-yoke
• In Japanese “ポカヨケ”
• The gimmick prevents mistake physically
• Example: Operator need shutdown a server
• When that the target server is used:
• Cannot shutdown

94. 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

95. Agenda
1. Human Error
2. How to notice human error factors?
3. How to reduce factors by engineering?
4. Approaches by engineering
5. Conclusion

96. CONCLUSION

97. 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

98. Conclusion
• Good approach:
• Easy to understand
• Simple ways
• Tend to notice a mistake
• Prevent/Safe a mistake

99. TMTOWTDI :)

100. Let’s find
the new safety approach!

101. Please vote me!

102. Thank you for listening

103. Any questions?