Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Technology for reduce of mistakes - うっかりをなくす技術

0 views

Published on

YAPC::Asia 2015
http://yapcasia.org/2015/talk/show/523b9508-0d77-11e5-8174-67dc7d574c3a

(Please review and teach me my English.)

Published in: Technology

Technology for reduce of mistakes - うっかりをなくす技術

  1. 1. Technology for reduce of mistakes id:karupaneura YAPC::Asia 2015 #yapcasiaD
  2. 2. Oops.. I forgot AC adaptor..
  3. 3. Thank you very very much!!!!
  4. 4. Hello, YAPC::Asia!!
  5. 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. 6. CPAN (PAUSE: KARUPA) • Time::Strptime • Geo::Hex::V3::XS • Test::SharedObject • Plack::App::Vhost • etc..
  7. 7. Gotanda.pm #6 • at 9/17(Tue) GaiaX Inc. • Join us! • http://gotanda.pm.org/
  8. 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. 9. Summary of this talk
  10. 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. 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. 12. Human Error
  13. 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. 14. What is human error?
  15. 15. Human error ≒ mistake
  16. 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. 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. 18. POINT: Human error is … • “System” means … • a infrastructure • a application • a source code • etc…
  19. 19. Why happen a human error?
  20. 20. Factor of human error • grouping by factor: • Human factor • Management factor • Environment factor
  21. 21. Human factors • Direct factor: • A carelessness • A mistake
  22. 22. Approach for human factors • Control arousal level • Pointing confirmation • Accident prediction training • NKY Training
  23. 23. Management factors • Indirect factor: • Not enough direction • Not enough review
  24. 24. Approach for management factors • Work flow improvements • Simplification of proces • Code review • Documentation • Automation
  25. 25. Environment factors • Indirect factor: • Difficult to understand • Complex ways • Tend to overlook a mistake • Tend to make mistakes
  26. 26. Approach for environment factors • Make it easy to understand • Simple ways • Tend to notice a mistake • Prevent/Safe a mistake
  27. 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. 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. 29. How to notice mistake factors?
  30. 30. near-miss • In Japanese “ヒヤリ・ハット” • Accidents that cause no loss/injuries/damage
  31. 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. 32. Heinrich's law serious accident slight accident near-miss frequency
  33. 33. POINT: Heinrich's law A mistake factor makes many near-misses
  34. 34. Be careful near-miss! • Tend to overlook • because not loss/injuries/damages • Resolving near-misses prevents incidents
  35. 35. How to find near-misses factors?
  36. 36. Collect the case of near-misses
  37. 37. How to collect the case of near-misses?
  38. 38. Github issue is awesome • Tag is awesome • CRITICAL/LITE/ARCH/CODE/etc.. • Engineer friendly • Easy to link with code
  39. 39. Code review • Get a operator points of view • Find a factor of near-miss • Create issue soon • Analyze and fix it
  40. 40. 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
  41. 41. Agenda 1. Human Error 2. How to notice human error factors? 3. How to reduce factors by engineering? 4. Approaches by engineering 5. Conclusion
  42. 42. How to reduce mistake factors by engineering?
  43. 43. Environment factors can be reduced by engineering
  44. 44. How to reduce environment factors?
  45. 45. Approaches • Easy to understand • Simple ways • Tend to notice a mistake • Prevent/Safe a mistake
  46. 46. break..
  47. 47. Agenda 1. Human Error 2. How to notice human error factors? 3. How to reduce factors by engineering? 4. Approaches by engineering 5. Conclusion
  48. 48. Approachs by engineering
  49. 49. Easy to understand
  50. 50. Easy to understand • Readable code • Descriptive naming • Code document/comment • Less side effects
  51. 51. Readable code • Read it!!!!!!!!!!!!!
  52. 52. Readable code READ IT SOON
  53. 53. Descriptive naming 帰れま10
  54. 54. Descriptive naming
  55. 55. Descriptive naming
  56. 56. Descriptive naming
  57. 57. 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.
  58. 58. Less side effects • No any side effects is best. • But, we uses ... • database • view • and ...
  59. 59. Less side effects • Approach: • (Don't use global variable) • Shorten object lifecycle • Immutable(Readonly) object/value • Functional programming
  60. 60. Shorten object lifecycle • Less status changes reduces side effects • Object has statuses • Make object in a minimum of scope
  61. 61. e.g. Sledge::Plugin::Stash
  62. 62. 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
  63. 63. Immutable object/value • Immutable variable: • Swift:let / Java:final / Kotlin:val / Scala:val • Perl: (Library makes readonly value) • Readonly.pm/Const.pm • Internals::SvREADONLY
  64. 64. Immutable object/value • Immutable object: • Value object pattern
  65. 65. 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.)
  66. 66. Simple ways
  67. 67. Simple ways • Immutable object/value • Shallow nested code • Modularization
  68. 68. 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
  69. 69. Modularization • Operation of the procedure should be a simple. • Operator need High-Level API • Practice structured programming
  70. 70. Tend to notice a mistake
  71. 71. Tend to notice a mistake • Type restriction/checking • strict.pm / warnings.pm (Perl) • Static code analysis (Perl::Critic/Perl::Lint) • Optional • Assertion • Automated test
  72. 72. Type restriction // Java package org.yapcasia.app; public class DB { public Prepare select (Query query) { // … } }
  73. 73. Type checking ## Perl use Smart::Args; sub select { args my $class => ‘ClassName’, my $sql => ‘FooDBI::Query’; … }
  74. 74. 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
  75. 75. 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*
  76. 76. 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
  77. 77. 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 …
  78. 78. 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
  79. 79. 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..)
  80. 80. Optional // Swift var foo : Int? = someNilableLogic() if let notNilFoo : Int = foo { // notNilFoo is not null } println(“(foo + 1)”) // it makes compile-time error
  81. 81. 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
  82. 82. Assertion /*** C ***/ int i = 1; i = add(i, 2); assert(i == 3); /* abort when `add` is broken */
  83. 83. 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
  84. 84. Automated test • No explanation needed :)
  85. 85. Prevent/Safe a mistake
  86. 86. Prevent/Safe a mistake • defer, guard object, try-with-resources • Max reqs per child • Poka-yoke
  87. 87. 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()
  88. 88. guard object ## Perl use Guard; my $sock = IO::Socket::INET->new(…); my $guard = guard { close($sock) }; …
  89. 89. try-with-resources ## Java7 try (FileReader r = new FileReader(filename)) { // … }
  90. 90. 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
  91. 91. 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
  92. 92. Poka-yoke • In Japanese “ポカヨケ” • The gimmick prevents mistake physically • Example: Operator need shutdown a server • When that the target server is used: • Cannot shutdown
  93. 93. 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
  94. 94. Agenda 1. Human Error 2. How to notice human error factors? 3. How to reduce factors by engineering? 4. Approaches by engineering 5. Conclusion
  95. 95. CONCLUSION
  96. 96. 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
  97. 97. Conclusion • Good approach: • Easy to understand • Simple ways • Tend to notice a mistake • Prevent/Safe a mistake
  98. 98. TMTOWTDI :)
  99. 99. Let’s find the new safety approach!
  100. 100. Please vote me!
  101. 101. Thank you for listening
  102. 102. Any questions?

×