10 Years of Python Libraries

Transcript

1. 1.

   10 Years of Python Libraries Armin “@mitsuhiko” Ronacher

2. 2.

   Who am I? { }

3. 3.

   Armin Ronacher Advisor and System Architect at Splash Damage /

   Fireteam Partner at Getsentry lucumr.pocoo.org/talks
4. 4.

   None
5. 5.

   Where I come from { }

6. 6.

   Hermagor Carinthia; Austria ( )

7. 7.

   Population: 6952

8. 8.

   Computer Scientists: 0

9. 9.

   The Internet to the rescue

10. 10.

    h 2003 Discovered Python

11. 11.

    9 2004 ubuntuusers.de

12. 12.

    n 2005 Pocoo!

13. 13.

    D 2005 WTF is CGI?

14. 14.

    h 2006 Colubrid GPL Licensed!

15. 15.

    h 2007 Licensing

16. 16.

    9 2009 Flask

17. 17.

    h 20?? Many, many more

18. 18.

    n Now Open Source Consulting

19. 19.

    How to Succeed { }

20. 20.

    you can only build what you use

21. 21.

    you can only build what you understand

22. 22.

    you can only build what you love

23. 23.

    be critical

24. 24.

    restrict your API

25. 25.

    license it well

26. 26.

    The Thing with Using { }

27. 27.

    chicken and egg situation:

28. 28.

    not enough to use it after building;

29. 29.

    how do you use something that does not exist?

30. 30.

    Iteration

31. 31.

    M ockups

32. 32.

    Use the Repl

33. 33.

    Learn to Throw Away

34. 34.

    Systems > Solutions

35. 35.

    one trick pony

36. 36.

    Understanding { }

37. 37.

    this is the trickiest part

38. 38.

    especially if you build something new

39. 39.

    Data Flow Transformation &

40. 40.

    context matters

41. 41.

    w Love what you build { }

42. 42.

    how do you know you found love?

43. 43.

    enjoy using it? :) do you …

44. 44.

    what if you found new love?

45. 45.

    admit mistakes

46. 46.

    give it someone else

47. 47.

    being critical { }

48. 48.

    it's normal to learn

49. 49.

    you might hate what you did a year ago

50. 50.

    second system syndrome careful though:

51. 51.

    Restrict your API { }

52. 52.

    APIs are Contracts __________________

53. 53.

    Contracts Expensive are

54. 54.

    maintenance complicates

55. 55.

    it's okay to keep things private

56. 56.

    you can make them public later on

57. 57.

    license it well { }

58. 58.

    consider the consequences

59. 59.

    licenses are forever

60. 60.

    API Design Goals { }

61. 61.

    stateless

62. 62.

    layered

63. 63.

    consistent

64. 64.

    small

65. 65.

    abstraction leakage

66. 66.

    documentation thou shall write

67. 67.

    ?