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

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

Gotanda.pm #6

• at 9/17(Tue) GaiaX Inc.

• Join us!

• http://gotanda.pm.org/

http://gotanda.pm.org/

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




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



• 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




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



break..

Agenda

1. Human Error




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

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 variable:

• Swift:let / Java:final / Kotlin:val / Scala:val

• Perl: (Library makes readonly value)

• Readonly.pm/Const.pm

• Internals::SvREADONLY


• 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


• 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




5. Conclusion

CONCLUSION

Conclusion

• Think in another developer's point of view

• “Is it easy to understand?”, “Is it simple?”


• Should store the case of near-misses

• GitHub issue is good

Conclusion

• Good approach:

• Easy to understand

• Simple ways



TMTOWTDI :)

Let’s find the new safety approach!

Please vote me!

Thank you for listening

Any questions?