• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Mlw
 

Mlw

on

  • 854 views

 

Statistics

Views

Total Views
854
Views on SlideShare
854
Embed Views
0

Actions

Likes
0
Downloads
0
Comments
0

0 Embeds 0

No embeds

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

    Mlw Mlw Presentation Transcript

    • Mind Like Water: The Path to Perl Bliss Peter Scott OSCON Portland, OR July 2006
    • The Way of This Talk “Soft” topics • Personality types and interactions • Beliefs and productive behaviors • Distilled wisdom of (Perl) masters •
    • Questions
    • Not… • What is the sound of one parenthesis grouping?
    • Not… • If a unit test fails but it’s testing unused code does it block a release?
    • But… • Which comes first, tests or code?
    • The Many Faces of Steve (and Bob, and Mary, and Bill, and Jane,…) • You are not a single person, but a constellation of personalities unique to you • This is the normal condition, not a disorder  And in no way invalidates disorders labeled after multiple personalities • It is a model, of course, but a convenient one • Each personality has different strengths, weaknesses, methods of learning, and goals • How well we understand and integrate them is key
    • Perl Personalities • Some personalities are common • And are dominant at different times • Personalities we likely have in common: The Perl Parser  The Impatient Coder  The Glory Hunter  The Good Samaritan  • Of course, YPMV • And there are others
    • The Perl Parser • A very primitive personality • Parses code and performs simulated execution • Limited stack space  This is why we require programs to be more readable than perl needs  And why variables should be declared in innermost scope possible  And why functions and methods should fit in a screen
    • A Beautiful Algorithm… for my $index ( 1 .. $pop->Count ) { my $head = $pop->Head( $index ); if ( head_okay( $head ) ) { my $body = $pop->Body( $index ); my $msg = quot;$headn$bodyquot;; if ( msg_okay( $msg ) ) { deliver( $msg ); } } }
    • A Beautiful Algorithm… Uglified for my $index ( 1 .. $pop->Count ) { print quot;Fetching message: $indexnquot;; my $head = $pop->Head( $index ); if ( head_okay( $head ) ) { print quot;Passed header check...nquot;; my $body = $pop->Body( $index ); my $msg = quot;$headn$bodyquot;; print quot;Length: quot;, length( $msg ), quot;nquot;; if ( msg_okay( $msg ) ) { print quot;Delivering...nquot;; deliver( $msg ); } } }
    • Enter Smart::Comments for my $index ( 1 .. $pop->Count ) { ### Fetching message: $index my $head = $pop->Head( $index ); if ( head_okay( $head ) ) { ### Passed header check... my $body = $pop->Body( $index ); my $msg = quot;$headn$bodyquot;; ### Length: length( $msg ) if ( msg_okay( $msg ) ) { ### Delivering... deliver( $msg ); } } }
    • With Syntax Coloring for my $index ( 1 .. $pop->Count ) { ### Fetching message: $index my $head = $pop->Head( $index ); if ( head_okay( $head ) ) { ### Passed header check... my $body = $pop->Body( $index ); my $msg = quot;$headn$bodyquot;; ### Length: length( $msg ) if ( msg_okay( $msg ) ) { ### Delivering... deliver( $msg ); } } }
    • The Perl Parser • It can actually be smarter than perl use constant MAX_USERS => 54; Readonly my $WINDOW_WIDTH = 640; … “Optimized away” • Needs to be integrated with: The Impatient Coder
    • The Impatient Coder • Wants to code now, sees no value in preparation Loves: Impatience as a virtue, Extreme • Programming Hates: Design, documentation, planning, • meetings, teamwork Needs to be integrated with: The Perl • Parser, The Good Samaritan Especially for picking identifier names •
    • The Glory Hunter • Thrives on attention • Wants to create works of art that will be admired throughout history • Dislikes sharing credit • Needs to be integrated with: The Good Samaritan
    • The Good Samaritan • Wants to make the world a better place for everyone • Wants to be needed • Enjoys teamwork and helping people • Needs to be integrated with: The Impatient Coder, The Glory Hunter
    • Why Test First Took So Long • Programmers have historically been dominated by the Glory Hunter personality  Because the discipline was largely an arcane priesthood  And their code was tested by other people • Now the Good Samaritan personality is ascendant • Integrating this can actually satisfy the Glory Hunter as well
    • Key Lessons • Get to know yourselves • Be smart enough to know when you’re not • Negotiate and balance  Within yourself  On a team • Glory Hunter conceives project and ensures its completion • Good Samaritan enlists cooperation • Impatient Coder gets the job done • Perl Parser ensures it’s comprehensible
    • Mind Like Water • Minimize the distractions • From the mundane…  Get your editor to do its share (defconst cperl-hairy t)
    • … to the Sublime • Use safety nets  Automated tests: http://qa.perl.org/test-modules.html • Factor out the boring rote stuff  Automated bootstrapping with module-starter (CPAN: Module::Starter)  Anything repetitive likely already has a module for automating it
    • The Behavioral Cycle • Beliefs shape Attitudes  Especially unconscious beliefs Attitudes drive behaviors • But it works the other way around too • Behaviors change attitudes • Attitudes can change beliefs • We can do this consciously •  It’s called discipline
    • Productive Perl Behaviors • Adopt best practices (wax on, wax off)  Whether or not you believe in them  Neatness  Precision • Program within your comprehension limits  And within those of the others who must read your code • Adopt large system methodologies for large systems  Largeness is in what it does, not how long it is
    • Secrets of the Masters Dominus • Damian • • brian d foy chromatic •
    • Excerpted Wisdom - MJD • Programming is not (always) a matter of personal taste. • I try to read and learn things that people around me are not reading and learning, because that tends to enable me to solve the problems that people around me are not able to solve. • I find myself saying that I don’t know and that I’m not sure a lot more than most programmers I know. • I read a lot of code written by other people and think about how it was done and why. • It seems like an awful lot of people […] don’t recognize that it would be a benefit to them to become less ignorant.
    • Excerpted Wisdom - Damian • I believe that it’s critical to work on what you love […] It increases my productivity enormously. • Often I simply will not admit failure […] I think most people throw in the towel too quickly […] I don’t assume a priori that something is impossible […] the limits in your mind are generally far below your actual limits. • Design from the users’ perspective, not from the implementers’. Design for the users’ convenience, not for the implementers’.
    • Excerpted Wisdom - Damian • Larry Wall has been a very important role model to me […] I’ve come to admire and respect his patience. I always want closure on a job… it’s been very enlightening to watch [him] leave things undone, and come back to them when the time was right. • I try and do something that stretches me as a coder [every day]. • Why do so many people seem to think that it’s easier to struggle to complete a job using only their existing tools/knowledge/skills, rather than first improving [those things] and then getting the job done more efficiently…?
    • Excerpted Wisdom - brian d foy • I work with the language the way it is instead of fighting it to make it more like something else […] Everything is the way it is for a reason. It doesn’t have to be a good reason, but there is a reason. • I’d rather go for the long term payoff than the short term satisfaction. • Ask more questions than you answer, and listen to the answer […] Don’t like the answer you get? Wait a week. The world will be different. Most things work themselves out. Don’t get impatient.
    • Excerpted Wisdom - brian d foy • If I come up with a way of thinking that seems to work, I try to apply it to something else to see if it still works. • The most puzzling thing is that people don’t simply try something. • I’ve learned quite a bit from Randal. He pokes his head into just about everything and brings back whatever he learns to his Perl programming.
    • Perl is Fun
    • Excerpted Wisdom - chromatic • I try to experiment with new ideas and code regularly. • I’m really picky about small details in a lot of ways. […] I’ve grown to rely on very consistent formatting. I even spend a lot of time trying to find good identifier names in almost-throwaway programs[…] • I find that rigorous discipline helps me keep good habits. • I appreciate how Ward Cunningham makes almost everything good in software look effortless.
    • Excerpted Wisdom - chromatic • It is painful to wake up early to exercise every morning, at least for the first few weeks, but after it becomes a habit, it’s painful not to do so. The same goes for good development practices, such as testing and working in small, reversible steps. • If I need to make a big change to a system, I try to make the change [that way]. In part, that means relying on effective testing and working as simply as possible. • I wonder why it’s easier [for many other people] to ask, in public, “Can I do task X in this way” than to write a five-line program to see.
    • Common Wisdom Extend yourself; try new things • Learn at every opportunity • Experiment; be curious • Integrate lessons from other fields • Persist • Use discipline to free yourself for important • tasks  Even when it appears superfluous • Be patient
    • Answers