Extreme Programming In Perl
Extreme Programming in PerlRobert NaglerFebruary 22, 2017Copyright c 2004 Robert NaglerLicensed under a Creative Commons Attribution 4.0 InternationalLicense nagler@extremeperl.org
ContentsPreface1 The1.11.21.31.41.51.6ixProblemSome Statistics . . . . . . .Risk Averse MethodologiesFostering Failure . . . . . .Get Me a Rock . . . . . . .Requirements Risk . . . . .Let’s Rock And Roll . . . .1223456.7899111213143 Perl3.1 Core Values . . . . . . . . .3.2 Customer-Orientation . . .3.3 Testing . . . . . . . . . . .3.4 CPAN . . . . . . . . . . . .3.5 Organizing Your Workshop.1717181919192 Extreme Programming2.1 Core Values . . . . .2.2 Communication . . .2.3 Simplicity . . . . . .2.4 Feedback . . . . . .2.5 Courage . . . . . . .2.6 The Practices . . . .2.7 Adopting XP . . . .4 Release Planning214.1 Planning Game . . . . . . . . . . . . . . . . . . . . . . . . . . 224.2 Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224.3 Stories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23iii
4.44.54.64.74.84.94.104.114.12On-site Customer .Story Cards . . . .Dead Wood . . . .Estimation . . . .Easing EstimationSpike Solutions . .Prioritization . . .All the Facts . . .Small Releases . .2324262828293031315 Iteration Planning5.1 Tasks . . . . . . . . . .5.2 The Meeting . . . . . .5.3 Get Me a Bucket . . . .5.4 Velocity . . . . . . . . .5.5 Watch Your Speed . . .5.6 Customer Priorities . . .5.7 Taking Care of Business5.8 The Beat Goes on . . .3333343535363637376 Pair Programming6.1 Quality . . . . . . . . . . . . . . .6.2 How It Works . . . . . . . . . . . .6.3 Ease on down the Road . . . . . .6.4 Rest & Relaxation . . . . . . . . .6.5 People Problems . . . . . . . . . .6.6 Different Strokes . . . . . . . . . .6.7 Yea, Whatever . . . . . . . . . . .6.8 Gumption Traps . . . . . . . . . .6.9 Reducing Risk Through Knowledge. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Transfer .393940414141434444457 Tracking7.1 Iteration Tracking . . . .7.2 Don’t Slip the Date . . . .7.3 Adding Tasks . . . . . . .7.4 The Tracker . . . . . . . .7.5 Release Tracking . . . . .7.6 What Goes Wrong? . . .7.7 Fixing Troubled Projects7.8 Meetings . . . . . . . . . .474848494950515455Copyright c 2004 Robert Naglernagler@extremeperl.org.iv
7.9 Show Your Stuff . . . . . . . . . . . . . . . . . . . . . . . . .7.10 Sign Off . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7.11 Here and Now . . . . . . . . . . . . . . . . . . . . . . . . . . .8 Acceptance Testing8.1 Acceptance Tests . . . . . . . . . . . . . .8.2 Automation . . . . . . . . . . . . . . . . .58section.8.38.4 Group Multiple Paths . . . . . . . . . . .8.5 Without Deviation, Testing Is Incomplete8.6 Subject Matter Oriented Programming . .8.7 Data-Driven Testing . . . . . . . . . . . .8.8 Empower The Customer to Test . . . . .9 Coding Style9.1 There’s More Than One Way To Do It .9.2 Give Me Consistency or Give Me Death9.3 Team Colors . . . . . . . . . . . . . . .9.4 An Example . . . . . . . . . . . . . . . .9.5 You Say, “if else”, And I Say, “? :”9.6 Once And Only Once . . . . . . . . . .9.7 Refactored Example . . . . . . . . . . .9.8 Change Log . . . . . . . . . . . . . . . .9.9 Refactoring . . . . . . . . . . . . . . . .9.10 Input Validation . . . . . . . . . . . . .9.11 You’d Rather Die . . . . . . . . . . . . .57. . . . . . . . . . . 57. . . . . . . . . . . 58.6061636466.67686869707273737578787910 Logistics11 Test-Driven Design11.1 Unit Tests . . . . . . . . . . . .11.2 Test First, By Intention . . . .11.3 Exponential Moving Average .11.4 Test Things That Might Break11.5 Satisfy The Test, Don’t Trick It11.6 Test Base Cases First . . . . .11.7 Choose Self-Evident Data . . .11.8 Use The Algorithm, Luke! . . .11.9 Fail Fast . . . . . . . . . . . . .11.10Deviance Testing . . . . . . . .Copyright c 2004 Robert 889909192v
11.11Only Test The New API . . . . . . . . . . . . . . . . . . . . .11.12Solid Foundation . . . . . . . . . . . . . . . . . . . . . . . . .12 Continuous Design12.1 Refactoring . . . . . . . . . . . . . . . . . .12.2 Simple Moving Average . . . . . . . . . . .12.3 SMA Unit Test . . . . . . . . . . . . . . . .12.4 SMA Implementation . . . . . . . . . . . .12.5 Move Common Features to a Base Class . .12.6 Refactor the Unit Tests . . . . . . . . . . .12.7 Fixing a Defect . . . . . . . . . . . . . . . .12.8 Global Refactoring . . . . . . . . . . . . . .12.9 Continuous Rennovation in the Real World12.10Simplify Accessors . . . . . . . . . . . . . .12.11Change Happens . . . . . . . . . . . . . . .9394.959697979810010210310510810911013 Unit Testing13.1 Testing Isn’t Hard . . . . . . . . . . . . . . .13.2 Mail::POP3Client . . . . . . . . . . . . . . .13.3 Make Assumptions . . . . . . . . . . . . . . .13.4 Test Data Dependent Algorithms . . . . . . .13.5 Validate Basic Assumptions First . . . . . . .13.6 Validate Using Implementation Knowledge . .13.7 Distinguish Error Cases Uniquely . . . . . . .13.8 Avoid Context Sensitive Returns . . . . . . .13.9 Use IO::Scalar for Files . . . . . . . . . . .13.10Perturb One Parameter per Deviance Case .13.11Relate Results When You Need To . . . . . .13.12Order Dependencies to Minimize Test Length13.13Consistent APIs Ease Testing . . . . . . . . .13.14Inject Failures . . . . . . . . . . . . . . . . . .13.15Mock Objects . . . . . . . . . . . . . . . . . .13.16Does It Work? . . . . . . . . . . . . . . . . 25.127. 128. 128. 128. 129. 13114 Refactoring14.1 Design on Demand . . . . . . . . .14.2 Mail::POP3Client . . . . . . . . .14.3 Remove Unused Code . . . . . . .14.4 Refactor Then Fix . . . . . . . . .14.5 Consistent Names Ease RefactoringCopyright c 2004 Robert Naglernagler@extremeperl.org.vi
14.6 Generate Repetitive Code . .14.7 Fix Once and Only Once . .14.8 Stylin’ . . . . . . . . . . . . .14.9 Tactics Versus Strategy . . .14.10Refactor With a Partner . . .14.11Sharing with Code References14.12Refactoring Illuminates Fixes14.13Brush and Floss Regularly . .15 It’s a SMOP15.1 The Problem . . . . . . . . . .15.2 Planning Game . . . . . . . . .15.3 Dividing the Story into Tasks .15.4 Coding Style . . . . . . . . . .15.5 Simple Design . . . . . . . . . .15.6 Imperative versus Declarative .15.7 Pair Programming . . . . . . .15.8 Test First, By Intention . . . .15.9 Statelessness . . . . . . . . . .15.10XML::Parser . . . . . . . . . .15.11First SMOP . . . . . . . . . . .15.12First Interpreter . . . . . . . .15.13Functional Programming . . . .15.14Outside In . . . . . . . . . . . .15.15May I, Please? . . . . . . . . .15.16Second Task . . . . . . . . . . .15.17Unit Test Maintenance . . . . .15.18Second SMOP . . . . . . . . .15.19Second SMOP Interpreter . . .15.20Spike Solutions . . . . . . . . .15.21Third Task . . . . . . . . . . .15.22Third SMOP . . . . . . . . . .15.23Third SMOP Interpreter . . . .15.24The Metaphor . . . . . . . . . .15.25Fourth Task . . . . . . . . . . .15.26Fourth SMOP . . . . . . . . . .15.27Fourth SMOP Interpreter . . .15.28Object-Oriented Programming15.29Success! . . . . . . . . . . . . .15.30Virtual Pair Programming . . .Copyright c 2004 Robert 141.143. 143. 144. 145. 146. 146. 147. 149. 149. 150. 151. 152. 153. 154. 155. 155. 156. 157. 158. 159. 160. 160. 162. 162. 164. 164. 166. 167. 168. 169. 169vii
15.31Open Source Development15.32Deviance Testing . . . . .15.33Final Implementation . .15.34Separate Concerns . . . .15.35 Travel Light . . . . . . .Copyright c 2004 Robert Naglernagler@extremeperl.orgwith. . . . . . . . .XP . . . . . . . . .170171172177178viii
PrefaceHave fun, and build something cool.– Pete BonhamThis book is about a marriage of two compatible yet unlikely partners.Extreme Programming (XP) is a software development methodology thatenables users, business people, programmers, and computers to communicate effectively. Perl is a dynamic programming language that lets an XPteam embrace the inevitable change caused by effective communication. Perlis the fixer and doer of the pair, and XP is the organizer and facilitator. Together they help you build robust software applications efficiently.Like any good marriage, the partners of Extreme Perl support each other.For example, XP asks business people to write acceptance tests, and Perl letsthe business people use their own language and tools for the tests. Muchof Perl only happens when the program runs, and XP asks programmersto define what is supposed to happen in unit tests before they write theprogram. In this book, you’ll see other examples where Perl reinforces XPand vice versa. This mutual support system is what makes Extreme Perlapplications robust.This book invites Perl programmers and their customers to take a freshlook at software development. Customers, and business people in general,will learn how XP enables customer-programmer communication for efficientand flexible requirements gathering. Programmers will see how XP’s focuson teamwork, incremental testing, and continuous design allows them to takepride in their craft. The numerous examples demonstrate Extreme Perl inaction, including the development of a complete, end-to-end application inthe last chapter.ix
To Business People and UsersXP combines your project responsibilities into a single official role: thecustomer. That’s the extent of the formalism. You don’t need to learn usecase modeling, object modeling, or even fashion modeling. You write yourrequirements on a piece of paper with pen. You even get to draw pictures,although the programmers would prefer you didn’t use crayon.As the customer, you have the responsibility to speak in one voice. Youcan discuss the requirements as much as you like, but in the end, you writedown a simple, clear requirement in your own language, called a story. Anydisagreements need to be settled during the planning game, where you andthe programmers hash out what needs to get done and how long it is goingto take.XP lets you change your mind. That means you have to hang around theprogrammers–something that may take getting used to. Programmers areterrible mind readers, and your immediate feedback is necessary when theyget the requirements wrong or you realize a requirement isn’t quite right.Best of all, you get to see progress right away. The programmers do thesimplest thing that could possibly work, and believe it or not, this actuallyproduces a working program in a matter of weeks. There’s nothing betterthan seeing your requirements embodied in software to ensure you are gettingwhat you want, and that you get what you are paying for. Everybody ismotivated by a working product in use.To Programmers and Their ManagersThe programming role is quite broad in XP. Programmers are responsiblefor listening to the customer, and reacting to the dynamic requirements ofthe customer’s world.With XP, you get to be real. No more fudged estimates or wild guesses.If the customer adds a complex requirement, like internationalization, rightin the middle of the project, it’s clearly not for free, and you get to say howlong it will take.XP managers are coaches and trackers. The programmers do all thework, and the coach gives sage advice while sipping martinis. If all goeswell, the tracker has a passive role, too. XP’s 12 simple practices add up toa lot of checks and balances. Sometimes the coach and tracker must remindthe programmers how to use the practices effectively, however.Code is the core artifact of an XP project. You have to like to code toCopyright c 2004 Robert Naglernagler@extremeperl.orgx
do XP. Fortunately, Perl is fun and easy to code. XP adds a modicum ofdiscipline to Perl coding practices that enables you to code faster and better.XP is reflective. The code gets better, because you refactor it frequently.This means you get to fix the bad code in the project that usually everybodyis afraid to touch. With XP, you might not be so afraid. You and your pairprogramming partner have lots of tests to ensure you don’t break anythingwhile refactoring.The goal of refactoring is to represent concepts once and only once. Perllets us do this more easily than other languages. Extreme Perl code canbe quite compact without obfuscation–rather the opposite. The code oftenevolves into what I call a subject matter oriented program (SMOP).Subject matter oriented programming distills the essence of the problem into a little language. The SMOPs in this book are plain old Perl.There’s no need to invent new syntax. Sometimes you may need to thinkdifferently to understand a SMOP unless you already are familiar withdeclarative programming, which is quite different than traditional imperative programming–what most programmers learn in school.You need to know Perl fairly well to read many of the examples. Iexplain the examples without going into much detail about the Perl syntaxand semantics. You may need to keep your favorite Perl reference bookwithin reach, for example, to undertand how map works.One last thing: the some of test examples use the bivio OLTP Platform(bOP), an open source application framework developed by my company (http://www.bivio.biz). If you write a lot of tests, you need tools to help youwrite them quickly and clearly. bOP employs SMOP to simplify unit andacceptance tests. I’m not trying to sell bOP to you–it’s free anyway–but todemonstrate SMOP in testing. This book explains just enough of bOP toread the examples.How to Read This BookThis book explains Extreme Perl to both programmers and business people.I also attempt to convey the Extreme Perl experience through examples andpersonal anecdotes. The book covers Extreme Programming (XP) in detail,so no prior experience is necessary.The first part of this book is about the non-programming aspects of Extreme Perl: the why (The Problem), the what (Extreme Programming andPerl) and the how (Release Planning, Iteration Planning, Acceptance Testing, Tracking, and Pair Programming). There is some code in AcceptanceCopyright c 2004 Robert Naglernagler@extremeperl.orgxi
Testing, but everybody should be able to read it. The last chapter (It’sa SMOP) is an end-to-end Extreme Perl example that combines XP, Perl,and SMOP. Non-programmers may want to scan this chapter and read theconclusions at the end.The second part of this book contains numerous programming examplesfrom the real world. The following chapters show you what it is like todo Extreme Perl: Coding Style, Logistics, Test-Driven Design, ContinuousDesign, Unit Testing, Refactoring, and It’s a SMOP.If you are a top-down thinker, I recommend you read this book front toback. Bottom-up thinkers may want to start at the last chapter and workbackwards.As noted in the previous section, the Perl code in this book is advanced.The programming examples are not complex, that is, they are short andcontain only a few concepts. However, the code may appear complicated tosome programmers. If you are familiar with functional programming andobject-oriented Perl, the examples should be clear. If not, you may wantto peek at the last chapter which describes functional programming. Thereferences throughout the book may be helpful, too. The object-orientedaspects are not all that important, so you should be able to understand theexamples without object-oriented experience.Typographical notes: I note acronyms that are used in the XP and Perlcommunities throughout this book, but I use their expansions so you don’thave to memorize them.AcknowledgmentsThis book was a collaborative project. Many people contributed to makethis book better. Any errors and omissions are my own despite the barrageof corrections from the from the following people. If I left out your name,please accept my apologies.To Joanne, thank you for your love, support, knowledge, active participation, and editing skills. This book would not have happened withoutyou.To Ben and Aidan, thanks for accepting the million just a minute’s, formanufacturing thousands of story cards, and for teaching me about life andpeople in the process. Living with children and practicing XP have much incommon.To Paul Moeller, thank you for being a brilliant business partner, friend,and programmer. Thanks for teaching me why there is no busy work inCopyright c 2004 Robert Naglernagler@extremeperl.orgxii
programming, and for saying and not saying what you thought about thisbook.To Ion Yadigaroglu, thank you for the thousand conversations, yoursupport, and for believing in me. And, for having the courage to leave theprogramming to the programmers.To Martin Lichtin, thank you for explaining that every layer of indirection creates a new software problem, and for helping me wade throughmyriad software problems over the years.Thanks to the bivions: Danny Ace, Annaliese Beery, Greg Compestine,Eric Dobbs, Eric Schell, David Farber, Justin Schell, and Tom Vilot. Youtook part in my crazy experiments, listened patiently to my lectures anddiatribes, and taught me much about programming, teamwork, and havingfun.Thanks to Johannes Rukkers for teaching me about applications programming in large organizations, and for the many enlightening conversations at the James Joyce and elsewhere.Thanks to Rob Ward for gallantly giving up your true name at O&A, foryears of patient guidance and support, and for smashing through the illogicand unEnglish in the many drafts of this book.Thanks to Stas Bekman, Justin Schell, and Alex Viggio for pair programming with me in the last chapter. You kept me on task, an
Extreme Programming (XP) is a software development methodology that enables users, business people, programmers, and computers to communi-cate e ectively. Perl is a dynamic programming language that lets an XP team embrace the inevitable change caused by e ective communication. Perl
Why Perl? Perl is built around regular expressions -REs are good for string processing -Therefore Perl is a good scripting language -Perl is especially popular for CGI scripts Perl makes full use of the power of UNIX Short Perl programs can be very short -"Perl is designed to make the easy jobs easy,
Perl can be embedded into web servers to speed up processing by as much as 2000%. Perl's mod_perl allows the Apache web server to embed a Perl interpreter. Perl's DBI package makes web-database integration easy. Perl is Interpreted Perl is an interpreted language, which means that your code can be run as is, without a
Other Perl resources from O’Reilly Related titles Learning Perl Programming Perl Advanced Perl Programming Perl Best Practices Perl Testing: A Developer’s . Intermedi
Run Perl Script Option 3: Create a Perl script my_script.pl: Run my_script.pl by calling perl: 8/31/2017 Introduction to Perl Basics I 10 print Hello World!\n; perl ./my_script.pl Option 4: For a small script with several lines, you can run it directly on the command line: perl -e print Hello World!\n;
Perl's creator, Larry Wall, announced it the next day in his State of the Onion address. Most notably, he said "Perl 6 is going to be designed by the community." Everyone thought that Perl 6 would be the version after the just-released Perl v5.6. That didn't happen, but that's why "Perl" was in the name "Perl 6."
tutorial Sorry about that but I have to keep my tutorial's example scripts short and to the point Finally, this is a tutorial for Perl/Tk only I will not be teaching perl here So if you know perl, continue But if you are a beginner to perl, I would recommend that you read my perl tutorial
Run Perl Script Option 3: Create a Perl script my_script.pl: Run my_script.pl by calling perl: 8/31/2017 Introduction to Perl Basics I 10 print Hello World!\n; perl ./my_script.pl Option 4: For a small script with several lines, you can run it directly on the command line: perl -e print Hello World!\n;
Introduction to Perl Pinkhas Nisanov. Perl culture Perl - Practical Extraction and Report Language Perl 1.0 released December 18, 1987 by Larry Wall. Perl culture Perl Poems BEFOREHAND: close door, each window & exit; wait until time. open spellbook, study, read (scan, select, tell us);
