Building better tools
Upcoming SlideShare
Loading in...5
×
 

Building better tools

on

  • 720 views

A talk on how system engineers and administrators, the people who maintain the infrastructure of the internet and who write a lot of code without (usually) having any training in software engineering ...

A talk on how system engineers and administrators, the people who maintain the infrastructure of the internet and who write a lot of code without (usually) having any training in software engineering practices, can improve their tools. Originally given at NYCBug in June 2009.

Statistics

Views

Total Views
720
Views on SlideShare
685
Embed Views
35

Actions

Likes
0
Downloads
4
Comments
0

7 Embeds 35

http://www.netmeister.org 15
http://coderwall.com 9
https://twimg0-a.akamaihd.net 6
http://www.linkedin.com 2
http://a0.twimg.com 1
https://si0.twimg.com 1
https://www.linkedin.com 1
More...

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Building better tools Building better tools Presentation Transcript

  • Building Better Tools Slide 1 Building Better Tools Jan Schaumann jschauma@netmeister.org 136D 027F DC29 8402 7B42 47D6 7C5B 64AF AF22 6A4CJan Schaumann June 3, 2009
  • Building Better Tools Slide 2whoami$ groupsnetbsd yahoo$Jan Schaumann June 3, 2009
  • Building Better Tools Slide 3whoami$ groupsnetbsd yahoo$Jan Schaumann June 3, 2009
  • Building Better Tools Slide 4whoami$ groupsnetbsd yahoo$Jan Schaumann June 3, 2009
  • Building Better Tools Slide 5A much better way to spend your time.Jan Schaumann June 3, 2009
  • Building Better Tools Slide 6People think the internet looks like this.Jan Schaumann June 3, 2009
  • Building Better Tools Slide 7In reality...Jan Schaumann June 3, 2009
  • Building Better Tools Slide 8ToolsJan Schaumann June 3, 2009
  • Building Better Tools Slide 9The right tool?Jan Schaumann June 3, 2009
  • Building Better Tools Slide 10The right tool?Jan Schaumann June 3, 2009
  • Building Better Tools Slide 11The right tool?Jan Schaumann June 3, 2009
  • Building Better Tools Slide 12The right tool?Jan Schaumann June 3, 2009
  • Building Better Tools Slide 13Internet RealityJan Schaumann June 3, 2009
  • Building Better Tools Slide 14Sturgeon’s Revelation 90% of everything is crud.Jan Schaumann June 3, 2009
  • Building Better Tools Slide 15A better hammer!Jan Schaumann June 3, 2009
  • Building Better Tools Slide 16Tools DevelopmentThree basic categories: scripting programming software developmentJan Schaumann June 3, 2009
  • Building Better Tools Slide 17Tools DevelopmentThree basic categories: scriptingJan Schaumann June 3, 2009
  • Building Better Tools Slide 18Tools DevelopmentThree basic categories: scripting automating very simple tasksJan Schaumann June 3, 2009
  • Building Better Tools Slide 19Tools DevelopmentThree basic categories: scripting automating very simple tasks customization of user environmentJan Schaumann June 3, 2009
  • Building Better Tools Slide 20Tools DevelopmentThree basic categories: scripting automating very simple tasks customization of user environment often only suitable for one individual userJan Schaumann June 3, 2009
  • Building Better Tools Slide 21Tools DevelopmentThree basic categories: scripting automating very simple tasks customization of user environment often only suitable for one individual user usually eventually evolves into larger programsJan Schaumann June 3, 2009
  • Building Better Tools Slide 22Tools DevelopmentThree basic categories: programmingJan Schaumann June 3, 2009
  • Building Better Tools Slide 23Tools DevelopmentThree basic categories: programmingJan Schaumann June 3, 2009
  • Building Better Tools Slide 24Tools DevelopmentThree basic categories: programming suitable for simple to moderately complex tasksJan Schaumann June 3, 2009
  • Building Better Tools Slide 25Tools DevelopmentThree basic categories: programming suitable for simple to moderately complex tasks results frequently used by a small base of usersJan Schaumann June 3, 2009
  • Building Better Tools Slide 26Tools DevelopmentThree basic categories: programming suitable for simple to moderately complex tasks results frequently used by a small base of users uses basic framework or common toolkitsJan Schaumann June 3, 2009
  • Building Better Tools Slide 27Tools DevelopmentThree 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 interfaceJan Schaumann June 3, 2009
  • Building Better Tools Slide 28Tools DevelopmentThree 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 productJan Schaumann June 3, 2009
  • Building Better Tools Slide 29Tools DevelopmentThree basic categories: software development Felton Pilate, MC Hammer’s producerJan Schaumann June 3, 2009
  • Building Better Tools Slide 30Tools DevelopmentThree basic categories: software developmentJan Schaumann June 3, 2009
  • Building Better Tools Slide 31Tools DevelopmentThree basic categories: software development required for any reasonably complex taskJan Schaumann June 3, 2009
  • Building Better Tools Slide 32Tools DevelopmentThree 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 33Tools DevelopmentThree basic categories: software development required for any reasonably complex task uses formal software engineering approach (measurable goals, requirements, specifications, ...) may evolve from previous prototypesJan Schaumann June 3, 2009
  • Building Better Tools Slide 34Tools DevelopmentThree 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 effortsJan Schaumann June 3, 2009
  • Building Better Tools Slide 35Evolution of the programming systems product F. Brooks, “The Mythical Man Month”Jan Schaumann June 3, 2009
  • Building Better Tools Slide 36Evolution 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 38Documentation “RTFM!”Jan Schaumann June 3, 2009
  • Building Better Tools Slide 39Documentation WTFMJan Schaumann June 3, 2009
  • Building Better Tools Slide 40User InterfaceJan Schaumann June 3, 2009
  • Building Better Tools Slide 41Unix PhilosophyJan Schaumann June 3, 2009
  • Building Better Tools Slide 42Unix Philosophy Do one thing and do it well.Jan Schaumann June 3, 2009
  • Building Better Tools Slide 43The KISS PrincipleJan Schaumann June 3, 2009
  • Building Better Tools Slide 44POLAPrinciple of Least AstonishmentJan Schaumann June 3, 2009
  • Building Better Tools Slide 45Test DrivenJan Schaumann June 3, 2009
  • Building Better Tools Slide 46The Zen of Python Beautiful is better than ugly.Jan Schaumann June 3, 2009
  • Building Better Tools Slide 47The Zen of Python Explicit is better than implicit.Jan Schaumann June 3, 2009
  • Building Better Tools Slide 48Explicit is better than implicit. Autovivification is Evil!$oink = { ’foo’ => { ’x’ => 1, }, ’bar’ => { ’y’ => 2, }, } ;if (exists($oink->{’baz’}{’z’})) { print "oink->baz->z existsn";}if (exists($oink->{’baz’})) { print "oink->baz existsn";}Jan Schaumann June 3, 2009
  • Building Better Tools Slide 49Explicit 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 50The Zen of Python Simple is better than complex. http://xkcd.com/399/Jan Schaumann June 3, 2009
  • Building Better Tools Slide 51The Zen of Python Complex is better than complicated.Jan Schaumann June 3, 2009
  • Building Better Tools Slide 52The Zen of Python Flat is better than nested.Jan Schaumann June 3, 2009
  • Building Better Tools Slide 53The Zen of Python Sparse is better than dense.Jan Schaumann June 3, 2009
  • Building Better Tools Slide 54The Zen of Python Readability counts.Jan Schaumann June 3, 2009
  • Building Better Tools Slide 55The Zen of Python Special cases aren’t special enough to break the rules.Jan Schaumann June 3, 2009
  • Building Better Tools Slide 56The 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 57The 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 58The Zen of Python Errors should never pass silently.Jan Schaumann June 3, 2009
  • Building Better Tools Slide 59The Zen of Python Errors should never pass silently. (That would be implicitly accepted failure.)Jan Schaumann June 3, 2009
  • Building Better Tools Slide 60The 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 61The 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 62The Zen of Python Errors should never pass silently. Unless explicitly silenced.Jan Schaumann June 3, 2009
  • Building Better Tools Slide 63The Zen of Python In the face of ambiguity, refuse the temptation to guess.Jan Schaumann June 3, 2009
  • Building Better Tools Slide 64The Zen of Python There should be one – and preferably only one – obvious way to do it.Jan Schaumann June 3, 2009
  • Building Better Tools Slide 65The Zen of Python There should be one – and preferably only one – obvious way to do it.Although that way may not be obvious at first unless you’re Dutch.Jan Schaumann June 3, 2009
  • Building Better Tools Slide 66The Zen of Python Now is better than never.Jan Schaumann June 3, 2009
  • Building Better Tools Slide 67The 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 68The Zen of Python If the implementation is hard to explain, it’s a bad idea.Jan Schaumann June 3, 2009
  • Building Better Tools Slide 69The 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 70A simple interface, easy to explain. Yet...Jan Schaumann June 3, 2009
  • Building Better Tools Slide 71The Zen of Python Namespaces are one honking great idea – let’s do more of those!Jan Schaumann June 3, 2009
  • Building Better Tools Slide 72ConsistencyJan Schaumann June 3, 2009
  • Building Better Tools Slide 73Robustness Principle or Postel’s Law Be conservative in what you do; be liberal in what you accept from others.Jan Schaumann June 3, 2009
  • Building Better Tools Slide 74Toss it!Jan Schaumann June 3, 2009
  • Building Better Tools Slide 75Avoid the Quick Fix There’s nothing as permanent as a temporary solution.Jan Schaumann June 3, 2009
  • Building Better Tools Slide 76Take a good look in the mirror! Nice Ass!Jan Schaumann June 3, 2009
  • Building Better Tools Slide 77Take 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 78Don’t try to be clever! insert clever sentence or image about how trying to beclever increases complexity and leads to code that is difficult to understand hereJan Schaumann June 3, 2009
  • Building Better Tools Slide 79Avoid 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 80Avoid Feature Creep http://www.feepingcreatures.comJan Schaumann June 3, 2009
  • Building Better Tools Slide 81Release Early, Release Often “More users find more bugs.” F. Brooks, “The Mythical Man Month”Jan Schaumann June 3, 2009
  • Building Better Tools Slide 82Increase the Bus Factor “Just friends.”Jan Schaumann June 3, 2009
  • Building Better Tools Slide 83Fix Broken WindowsJan Schaumann June 3, 2009
  • Building Better Tools Slide 84Program 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 85Toss it!Jan Schaumann June 3, 2009
  • Building Better Tools Slide 86Starting freshJan Schaumann June 3, 2009
  • Building Better Tools Slide 87OwnershipJan Schaumann June 3, 2009
  • Building Better Tools Slide 88Done!Jan Schaumann June 3, 2009