Post on 30-May-2015
description
transcript
Building Better Tools Slide 1
Building Better Tools
Jan Schaumannjschauma@netmeister.org
136D 027F DC29 8402 7B42 47D6 7C5B 64AF AF22 6A4C
Jan Schaumann June 3, 2009
Building Better Tools Slide 2
whoami
$ groups
netbsd yahoo
$
Jan Schaumann June 3, 2009
Building Better Tools Slide 3
whoami
$ groups
netbsd yahoo
$
Jan Schaumann June 3, 2009
Building Better Tools Slide 4
whoami
$ groups
netbsd yahoo
$
Jan Schaumann June 3, 2009
Building Better Tools Slide 5
A much better way to spend your time.
Jan Schaumann June 3, 2009
Building Better Tools Slide 6
People think the internet looks like this.
Jan Schaumann June 3, 2009
Building Better Tools Slide 7
In reality...
Jan Schaumann June 3, 2009
Building Better Tools Slide 8
Tools
Jan Schaumann June 3, 2009
Building Better Tools Slide 9
The right tool?
Jan Schaumann June 3, 2009
Building Better Tools Slide 10
The right tool?
Jan Schaumann June 3, 2009
Building Better Tools Slide 11
The right tool?
Jan Schaumann June 3, 2009
Building Better Tools Slide 12
The right tool?
Jan Schaumann June 3, 2009
Building Better Tools Slide 13
Internet Reality
Jan Schaumann June 3, 2009
Building Better Tools Slide 14
Sturgeon’s Revelation
90% of everything is crud.
Jan Schaumann June 3, 2009
Building Better Tools Slide 15
A better hammer!
Jan Schaumann June 3, 2009
Building Better Tools Slide 16
Tools Development
Three basic categories:
scripting
programming
software development
Jan Schaumann June 3, 2009
Building Better Tools Slide 17
Tools Development
Three basic categories:
scripting
Jan Schaumann June 3, 2009
Building Better Tools Slide 18
Tools Development
Three basic categories:
scripting
automating very simple tasks
Jan Schaumann June 3, 2009
Building Better Tools Slide 19
Tools Development
Three basic categories:
scripting
automating very simple tasks
customization of user environment
Jan Schaumann June 3, 2009
Building Better Tools Slide 20
Tools Development
Three basic categories:
scripting
automating very simple tasks
customization of user environment
often only suitable for one individual user
Jan Schaumann June 3, 2009
Building Better Tools Slide 21
Tools Development
Three basic categories:
scripting
automating very simple tasks
customization of user environment
often only suitable for one individual user
usually eventually evolves into larger programs
Jan Schaumann June 3, 2009
Building Better Tools Slide 22
Tools Development
Three basic categories:
programming
Jan Schaumann June 3, 2009
Building Better Tools Slide 23
Tools Development
Three basic categories:
programming
Jan Schaumann June 3, 2009
Building Better Tools Slide 24
Tools Development
Three basic categories:
programming
suitable for simple to moderately complex tasks
Jan Schaumann June 3, 2009
Building Better Tools Slide 25
Tools Development
Three basic categories:
programming
suitable for simple to moderately complex tasks
results frequently used by a small base of users
Jan Schaumann June 3, 2009
Building Better Tools Slide 26
Tools Development
Three basic categories:
programming
suitable for simple to moderately complex tasks
results frequently used by a small base of users
uses basic framework or common toolkits
Jan Schaumann June 3, 2009
Building Better Tools Slide 27
Tools Development
Three basic categories:
programming
suitable for simple to moderately complex tasks
results frequently used by a small base of users
uses basic framework or common toolkits
provides consistent interface
Jan Schaumann June 3, 2009
Building Better Tools Slide 28
Tools Development
Three basic categories:
programming
suitable for simple to moderately complex tasks
results frequently used by a small base of users
uses basic framework or common toolkits
provides consistent interface
may evolve into full product
Jan Schaumann June 3, 2009
Building Better Tools Slide 29
Tools Development
Three basic categories:
software development
Felton Pilate, MC Hammer’s producer
Jan Schaumann June 3, 2009
Building Better Tools Slide 30
Tools Development
Three basic categories:
software development
Jan Schaumann June 3, 2009
Building Better Tools Slide 31
Tools Development
Three basic categories:
software development
required for any reasonably complex task
Jan Schaumann June 3, 2009
Building Better Tools Slide 32
Tools Development
Three basic categories:
software development
required for any reasonably complex task
uses formal software engineering approach (measurable goals, requirements,specifications, ...)
Jan Schaumann June 3, 2009
Building Better Tools Slide 33
Tools Development
Three basic categories:
software development
required for any reasonably complex task
uses formal software engineering approach (measurable goals, requirements,specifications, ...)
may evolve from previous prototypes
Jan Schaumann June 3, 2009
Building Better Tools Slide 34
Tools Development
Three basic categories:
software development
required for any reasonably complex task
uses formal software engineering approach (measurable goals, requirements,specifications, ...)
may evolve from previous prototypes
requires ongoing continous maintenance / development efforts
Jan Schaumann June 3, 2009
Building Better Tools Slide 35
Evolution of the programming systems product
F. Brooks, “The Mythical Man Month”
Jan Schaumann June 3, 2009
Building Better Tools Slide 36
Evolution of the programming systems product
F. Brooks, “The Mythical Man Month”
Jan Schaumann June 3, 2009
Building Better Tools Slide 37
“Trust me, I know what I’m doing.”
Jan Schaumann June 3, 2009
Building Better Tools Slide 38
Documentation
“RTFM!”
Jan Schaumann June 3, 2009
Building Better Tools Slide 39
Documentation
WTFM
Jan Schaumann June 3, 2009
Building Better Tools Slide 40
User Interface
Jan Schaumann June 3, 2009
Building Better Tools Slide 41
Unix Philosophy
Jan Schaumann June 3, 2009
Building Better Tools Slide 42
Unix Philosophy
Do one thing and do it well.
Jan Schaumann June 3, 2009
Building Better Tools Slide 43
The KISS Principle
Jan Schaumann June 3, 2009
Building Better Tools Slide 44
POLA
Principle of Least Astonishment
Jan Schaumann June 3, 2009
Building Better Tools Slide 45
Test Driven
Jan Schaumann June 3, 2009
Building Better Tools Slide 46
The Zen of Python
Beautiful is better than ugly.
Jan Schaumann June 3, 2009
Building Better Tools Slide 47
The Zen of Python
Explicit is better than implicit.
Jan Schaumann June 3, 2009
Building Better Tools Slide 48
Explicit is better than implicit.
Autovivification is Evil!
$oink = { ’foo’ => { ’x’ => 1, },
’bar’ => { ’y’ => 2, },
} ;
if (exists($oink->{’baz’}{’z’})) {
print "oink->baz->z exists\n";
}
if (exists($oink->{’baz’})) {
print "oink->baz exists\n";
}
Jan Schaumann June 3, 2009
Building Better Tools Slide 49
Explicit is better than implicit.
For $Deity’s sake, return something.
sub func {
my ($ref, $ref_or_is_it_something_else) = @_;
for my $a (@{$ref}) {
if (condition) {
return 1;
}
}
}
Jan Schaumann June 3, 2009
Building Better Tools Slide 50
The Zen of Python
Simple is better than complex.
http://xkcd.com/399/
Jan Schaumann June 3, 2009
Building Better Tools Slide 51
The Zen of Python
Complex is better than complicated.
Jan Schaumann June 3, 2009
Building Better Tools Slide 52
The Zen of Python
Flat is better than nested.
Jan Schaumann June 3, 2009
Building Better Tools Slide 53
The Zen of Python
Sparse is better than dense.
Jan Schaumann June 3, 2009
Building Better Tools Slide 54
The Zen of Python
Readability counts.
Jan Schaumann June 3, 2009
Building Better Tools Slide 55
The Zen of Python
Special cases aren’t special enough to break the rules.
Jan Schaumann June 3, 2009
Building Better Tools Slide 56
The Zen of Python
Special cases aren’t special enough to break the rules.
Although practicality beats purity.
Jan Schaumann June 3, 2009
Building Better Tools Slide 57
The Zen of Python
Special cases aren’t special enough to break the rules.
Although practicality beats purity.
Sturgeon’s Law: Nothing is always absolutely so.
Jan Schaumann June 3, 2009
Building Better Tools Slide 58
The Zen of Python
Errors should never pass silently.
Jan Schaumann June 3, 2009
Building Better Tools Slide 59
The Zen of Python
Errors should never pass silently.(That would be implicitly accepted failure.)
Jan Schaumann June 3, 2009
Building Better Tools Slide 60
The Zen of Python
Errors should never pass silently.(That would be implicitly accepted failure.)
(You know what would be better than something implicit?)
Jan Schaumann June 3, 2009
Building Better Tools Slide 61
The Zen of Python
Errors should never pass silently.(That would be implicitly accepted failure.)
(You know what would be better than something implicit?)
(Why, of course, something explicit!)
Jan Schaumann June 3, 2009
Building Better Tools Slide 62
The Zen of Python
Errors should never pass silently.
Unless explicitly silenced.
Jan Schaumann June 3, 2009
Building Better Tools Slide 63
The Zen of Python
In the face of ambiguity, refuse the temptation to guess.
Jan Schaumann June 3, 2009
Building Better Tools Slide 64
The Zen of Python
There should be one – and preferably only one – obviousway to do it.
Jan Schaumann June 3, 2009
Building Better Tools Slide 65
The Zen of Python
There should be one – and preferably only one – obviousway to do it.
Although that way may not be obvious at first unless you’reDutch.
Jan Schaumann June 3, 2009
Building Better Tools Slide 66
The Zen of Python
Now is better than never.
Jan Schaumann June 3, 2009
Building Better Tools Slide 67
The Zen of Python
Now is better than never.
Although never is often better than right now.
Jan Schaumann June 3, 2009
Building Better Tools Slide 68
The Zen of Python
If the implementation is hard to explain, it’s a bad idea.
Jan Schaumann June 3, 2009
Building Better Tools Slide 69
The Zen of Python
If the implementation is easy to explain,it may be a good idea.
Jan Schaumann June 3, 2009
Building Better Tools Slide 70
A simple interface, easy to explain. Yet...
Jan Schaumann June 3, 2009
Building Better Tools Slide 71
The Zen of Python
Namespaces are one honking great idea –let’s do more of those!
Jan Schaumann June 3, 2009
Building Better Tools Slide 72
Consistency
Jan Schaumann June 3, 2009
Building Better Tools Slide 73
Robustness Principle or Postel’s Law
Be conservative in what you do; be liberal in what youaccept from others.
Jan Schaumann June 3, 2009
Building Better Tools Slide 74
Toss it!
Jan Schaumann June 3, 2009
Building Better Tools Slide 75
Avoid the Quick Fix
There’s nothing as permanent as a temporary solution.
Jan Schaumann June 3, 2009
Building Better Tools Slide 76
Take a good look in the mirror!
Nice Ass!
Jan Schaumann June 3, 2009
Building Better Tools Slide 77
Take a good look in the mirror!
Until you can prove otherwise,assume that you are an Ass!
Jan Schaumann June 3, 2009
Building Better Tools Slide 78
Don’t try to be clever!
insert
clever sentence or image about how trying to be
clever increases complexity and leads to code that
is difficult to understand
here
Jan Schaumann June 3, 2009
Building Better Tools Slide 79
Avoid the Project That Was Never Finished
Don’t let the Perfect be the enemy of the Good.
Jan Schaumann June 3, 2009
Building Better Tools Slide 80
Avoid Feature Creep
http://www.feepingcreatures.com
Jan Schaumann June 3, 2009
Building Better Tools Slide 81
Release Early, Release Often
“More users find more bugs.”F. Brooks, “The Mythical Man Month”
Jan Schaumann June 3, 2009
Building Better Tools Slide 82
Increase the Bus Factor
“Just friends.”
Jan Schaumann June 3, 2009
Building Better Tools Slide 83
Fix Broken Windows
Jan Schaumann June 3, 2009
Building Better Tools Slide 84
Program Maintenance
“... is an entropy-increasing process, and even its mostskillful execution only delays the subsidence of the system
into unfixable obsolescence.”F. Brooks, “The Mythical Man Month”
Jan Schaumann June 3, 2009
Building Better Tools Slide 85
Toss it!
Jan Schaumann June 3, 2009
Building Better Tools Slide 86
Starting fresh
Jan Schaumann June 3, 2009
Building Better Tools Slide 87
Ownership
Jan Schaumann June 3, 2009
Building Better Tools Slide 88
Done!
Jan Schaumann June 3, 2009