DOCSLIB.ORG

Advanced Perl Programming

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Advanced Perl Programming ;-_=_Scrolldown to the Underground_=_-; Advanced Perl Programming http://kickme.to/tiger/ By Sriram Srinivasan; ISBN 1-56592-220-4, 434 pages. First Edition, August 1997. (See the catalog page for this book.) Search the text of Advanced Perl Programming. Index Symbols | A | B | C | D | E | F | G | H | I | J | K | L | M | N | O | P | Q | R | S | T | U | V | W | X | Y | Z Table of Contents Preface Chapter 1: Data References and Anonymous Storage Chapter 2: Implementing Complex Data Structures Chapter 3: Typeglobs and Symbol Tables Chapter 4: Subroutine References and Closures Chapter 5: Eval Chapter 6: Modules Chapter 7: Object-Oriented Programming Chapter 8: Object Orientation: The Next Few Steps Chapter 9: Tie Chapter 10: Persistence Chapter 11: Implementing Object Persistence Chapter 12: Networking with Sockets Chapter 13: Networking: Implementing RPC Chapter 14: User Interfaces with Tk Chapter 15: GUI Example: Tetris Chapter 16: GUI Example: Man Page Viewer Chapter 17: Template-Driven Code Generation Chapter 18: Extending Perl:A First Course Chapter 19: Embedding Perl:The Easy Way Chapter 20: Perl Internals Appendix A: Tk Widget Reference Appendix B: Syntax Summary Examples The Perl CD Bookshelf Navigation Copyright © 1999 O'Reilly & Associates. All Rights Reserved. Preface Next: Why Perl? Preface Contents: The Case for Scripting Why Perl? What Must I Know? The Book's Approach Conventions Resources Perl Resources We'd Like to Hear from You Acknowledgments Errors, like straws, upon the surface flow; He who would search for pearls must dive below. - John Dryden, All for Love, Prologue This book has two goals: to make you a Perl expert, and, at a broader level, to supplement your current arsenal of techniques and tools for crafting applications. It covers advanced features of the Perl language, teaches you how the perl interpreter works, and presents areas of modern computing technology such as networking, user interfaces, persistence, and code generation. You will not merely dabble with language syntax or the APIs of different modules as you read this book. You will spend just as much time dealing with real-world issues such as avoiding deadlocks during remote procedure calls and switching smoothly between data storage using a flat file or a database. Along the way, you'll become comfortable with such Perl techniques as run-time evaluation, nested data structures, objects, and closures. This book expects you to know the essentials of Perl - a minimal subset, actually; you must be conversant with the basic data types (scalars, arrays, and hashes), regular expressions, subroutines, basic control structures (if, while, unless, for, foreach), file I/O, and standard variables such as @ARGV and $_. Should this not be the case, I recommend Randal Schwartz and Tom Christiansen's excellent tutorial, Learning Perl, Second Edition. The book - in particular, this preface - substantiates two convictions of mine. The first is that a two-language approach is most appropriate for tackling typical large-application projects: a scripting language (such as Perl, Visual Basic, Python, or Tcl) in conjunction with a systems programming language (C, C++, Java). A scripting language has weak compile-time type checking, has high-level data structures (for instance, Perl's hash table is a fundamental type; C has no such thing), and does not typically have a separate compilation-linking phase. A systems programming language is typically closer to the operating system, has fine-grained data types (C has short, int, long, unsigned int, float, double, and so on, whereas Perl has a scalar data type), and is typically faster than interpreted languages. Perl spans the language spectrum to a considerable degree: It performs extremely well as a scripting language, yet gives you low-level access to operating system API, is much faster than Java (as this book goes to press), and can optionally be compiled. The distinction between scripting and systems programming languages is a contentious one, but it has served me well in practice. This point will be underscored in the last three chapters of the book (on extending Perl, embedding Perl, and Perl internals). I believe that neither type of language is properly equipped to handle sophisticated application projects satisfactorily on its own, and I hope to make the case for Perl and C/C++ as the two-language combination mentioned earlier. Of course, it would be most gratifying, or totally tubular, as the local kids are wont to say, if the design patterns and lessons learned in this book help you even if you were to choose other languages. The second conviction of mine is that to deploy effective applications, it is not enough just to know the language syntax well. You must know, in addition, the internals of the language's environment, and you must have a solid command of technology areas such as networking, user interfaces, databases, and so forth (specially issues that transcend language-specific libraries). Let's look at these two points in greater detail. The Case for Scripting I started my professional life building entire applications in assembler, on occasion worrying about trying to save 100 bytes of space and optimizing away that one extra instruction. C and PL/M changed my world view. I found myself getting a chance to reflect on the application as a whole, on the life-cycle of the project, and on how it was being used by the end-user. Still, where efficiency was paramount, as was the case for interrupt service routines, I continued with assembler. (Looking back, I suspect that the PL/M compiler could generate far better assembly code than I, but my vanity would have prevented such an admission.) My applications' requirements continued to increase in complexity; in addition to dealing with graphical user interfaces, transactions, security, network transparency, and heterogeneous platforms, I began to get involved in designing software architectures for problems such as aircraft scheduling and network management. My own efficiency had become a much more limiting factor than that of the applications. While object orientation was making me more effective at the design level, the implementation language, C++, and the libraries and tools available weren't helping me raise my level of programming. I was still dealing with low-level issues such as constructing frameworks for dynamic arrays, meta-data, text manipulation, and memory management. Unfortunately, environments such as Eiffel, Smalltalk, and the NeXT system that dealt with these issues effectively were never a very practical choice for my organization. You might understand why I have now become a raucous cheerleader for Java as the application development language of choice. The story doesn't end there, though. Lately, the realization has slowly crept up on me that I have been ignoring two big time-sinks at either end of a software life-cycle. At the designing end, sometimes the only way to clearly understand the problem is to create an electronic storyboard (prototype). And later, once the software is implemented, users are always persnickety (er, discerning) about everything they can see, which means that even simple form-based interfaces are constantly tweaked and new types of reports are constantly requested. And, of course, the sharper developers wish to move on to the next project as soon as the software is implemented. These are occasions when scripting languages shine. They provide quick turnaround, dynamic user interfaces, terrific facilities for text handling, run-time evaluation, and good connections to databases and networks. Best of all, they don't need prima donna programmers to baby-sit them. You can focus your attention on making the application much more user-centric, instead of trying to figure out how to draw a pie chart using Xlib's[1] lines and circles. [1] X Windows Library. Someone once mentioned that programming X Windows is like taking the square root of a number using Roman numerals! Clearly, it is not practical to develop complex applications in a scripting language alone; you still want to retain features such as performance, fine-grained data structures, and type safety (crucial when many programmers are working on one problem). This is why I am now an enthusiastic supporter of using scripting languages along with C/C++ (or Java when it becomes practical in terms of performance). Many people have been reaping enormous benefits from this component-based approach, in which the components are written in C and woven together using a scripting language. Just ask any of the zillions of Visual Basic, PowerBuilder, Delphi, Tcl, and Perl programmers - or, for that matter, Microsoft Office and Emacs users. For a much more informed and eloquent (not to mention controversial) testimonial to the scripting approach, please read the paper by Dr. John Ousterhout,[2] available at http://www.scriptics.com/people/john.ousterhout/. [2] Inventor of Tcl (Tool Command Language, pronounced "tickle"). For an even better feel for this argument, play with the Tcl plug-in for Netscape (from the same address), take a look at the sources for Tcl applets ("Tclets"), and notice how compactly you can solve simple problems. A 100-line applet for a calculator, including the UI? I suspect that an equivalent Java applet would not take fewer than 800 lines and would be far less flexible. Advanced Perl Next: Why Programming Perl? Book Why Perl? Index [ Library Home | Perl in a Nutshell | Learning Perl | Learning Perl on Win32 | Programming Perl | Advanced Perl Programming | Perl Cookbook ] Previous: The Case for Preface Next: What Scripting Must I Know? Why Perl? So why Perl, then, and not Visual Basic, Tcl, or Python? Although Visual Basic is an excellent choice on a Wintel[3] PC, it's not around on any other platform, so it has not been a practical choice for me.
Load more

Recommended publications
  • Bbedit 13.5 User Manual
    User Manual BBEdit™ Professional Code and Text Editor for the Macintosh Bare Bones Software, Inc. ™ BBEdit 13.5 Product Design Jim Correia, Rich Siegel, Steve Kalkwarf, Patrick Woolsey Product Engineering Jim Correia, Seth Dillingham, Matt Henderson, Jon Hueras, Steve Kalkwarf, Rich Siegel, Steve Sisak Engineers Emeritus Chris Borton, Tom Emerson, Pete Gontier, Jamie McCarthy, John Norstad, Jon Pugh, Mark Romano, Eric Slosser, Rob Vaterlaus Documentation Fritz Anderson, Philip Borenstein, Stephen Chernicoff, John Gruber, Jeff Mattson, Jerry Kindall, Caroline Rose, Allan Rouselle, Rich Siegel, Vicky Wong, Patrick Woolsey Additional Engineering Polaschek Computing Icon Design Bryan Bell Factory Color Schemes Luke Andrews Additional Color Schemes Toothpaste by Cat Noon, and Xcode Dark by Andrew Carter. Used by permission. Additional Icons By icons8. Used under license Additional Artwork By Jonathan Hunt PHP keyword lists Contributed by Ted Stresen-Reuter. Previous versions by Carsten Blüm Published by: Bare Bones Software, Inc. 73 Princeton Street, Suite 206 North Chelmsford, MA 01863 USA (978) 251-0500 main (978) 251-0525 fax https://www.barebones.com/ Sales & customer service: [email protected] Technical support: [email protected] BBEdit and the BBEdit User Manual are copyright ©1992-2020 Bare Bones Software, Inc. All rights reserved. Produced/published in USA. Copyrights, Licenses & Trademarks cmark ©2014 by John MacFarlane. Used under license; part of the CommonMark project LibNcFTP Used under license from and copyright © 1996-2010 Mike Gleason & NcFTP Software Exuberant ctags ©1996-2004 Darren Hiebert (source code here) PCRE2 Library Written by Philip Hazel and Zoltán Herczeg ©1997-2018 University of Cambridge, England Info-ZIP Library ©1990-2009 Info-ZIP.
    [Show full text]
  • Intermediate Perl – Session 7
    1.1.2.8 – Intermediate Perl 1.1.2.8.7 Intermediate Perl – Session 7 · POD – plain old documentation · processing command line parameters · processing configuration files 9/23/2008 1.1.2.8.7 - Intermediate Perl - POD, parameters and configuration 1 1.1.2.8 – Intermediate Perl POD – plain old documentation ·embed documentation in your scripts with POD ·POD is very simple because it stands for Plain Old Documentation · it is meant to be easy to use – and it is! · POD is a simple markup language · write documentation once and export it to multiple formats · man, html, text · POD formatting codes are embedded in your script ·Pod::Usage module displays documentation for the script when the script is executed · how handy is that? 9/23/2008 1.1.2.8.7 - Intermediate Perl - POD, parameters and configuration 2 1.1.2.8 – Intermediate Perl POD structure – sections start and end pod with =pod =pod and =cut =head1 NAME script – take over the world in one line of Perl separate paragraphs by =head1 SYNOPSIS new lines script –mode EVIL|GOOD [-debug] use =head1 and =head2 =head1 DESCRIPTION for headings You can take over the world as an EVIL doer or a GOOD doer. Pick one. =head2 EVIL indent code Evil is more fun. =head2 GOOD =over and =back to =over indent text =item * advantages =item * for bullet lists none =item * disadvantages no fun =back =cut 9/23/2008 1.1.2.8.7 - Intermediate Perl - POD, parameters and configuration 3 1.1.2.8 – Intermediate Perl POD structure – ordinary paragraphs ordinary paragraphs # contents of podexample =pod representing text that =head1 EXAMPLE you'd like wrapped and justified have no This is an ordinary paragraph that will be indented, wrapped and maybe even justified.
    [Show full text]
  • "This Book Was a Joy to Read. It Covered All Sorts of Techniques for Debugging, Including 'Defensive' Paradigms That Will Eliminate Bugs in the First Place
    Perl Debugged By Peter Scott, Ed Wright Publisher : Addison Wesley Pub Date : March 01, 2001 ISBN : 0-201-70054-9 Table of • Pages : 288 Contents "This book was a joy to read. It covered all sorts of techniques for debugging, including 'defensive' paradigms that will eliminate bugs in the first place. As coach of the USA Programming Team, I find the most difficult thing to teach is debugging. This is the first text I've even heard of that attacks the problem. It does a fine job. Please encourage these guys to write more." -Rob Kolstad Perl Debugged provides the expertise and solutions developers require for coding better, faster, and more reliably in Perl. Focusing on debugging, the most vexing aspect of programming in Perl, this example-rich reference and how-to guide minimizes development, troubleshooting, and maintenance time resulting in the creation of elegant and error-free Perl code. Designed for the novice to intermediate software developer, Perl Debugged will save the programmer time and frustration in debugging Perl programs. Based on the authors' extensive experience with the language, this book guides developers through the entire programming process, tackling the benefits, plights, and pitfalls of Perl programming. Beginning with a guided tour of the Perl documentation, the book progresses to debugging, testing, and performance issues, and also devotes a chapter to CGI programming in Perl. Throughout the book, the authors espouse defensible paradigms for improving the accuracy and performance of Perl code. In addition, Perl Debugged includes Scott and Wright's "Perls of Wisdom" which summarize key ideas from each of the chapters, and an appendix containing a comprehensive listing of Perl debugger commands.
    [Show full text]
  • EN-Google Hacks.Pdf
    Table of Contents Credits Foreword Preface Chapter 1. Searching Google 1. Setting Preferences 2. Language Tools 3. Anatomy of a Search Result 4. Specialized Vocabularies: Slang and Terminology 5. Getting Around the 10 Word Limit 6. Word Order Matters 7. Repetition Matters 8. Mixing Syntaxes 9. Hacking Google URLs 10. Hacking Google Search Forms 11. Date-Range Searching 12. Understanding and Using Julian Dates 13. Using Full-Word Wildcards 14. inurl: Versus site: 15. Checking Spelling 16. Consulting the Dictionary 17. Consulting the Phonebook 18. Tracking Stocks 19. Google Interface for Translators 20. Searching Article Archives 21. Finding Directories of Information 22. Finding Technical Definitions 23. Finding Weblog Commentary 24. The Google Toolbar 25. The Mozilla Google Toolbar 26. The Quick Search Toolbar 27. GAPIS 28. Googling with Bookmarklets Chapter 2. Google Special Services and Collections 29. Google Directory 30. Google Groups 31. Google Images 32. Google News 33. Google Catalogs 34. Froogle 35. Google Labs Chapter 3. Third-Party Google Services 36. XooMLe: The Google API in Plain Old XML 37. Google by Email 38. Simplifying Google Groups URLs 39. What Does Google Think Of... 40. GooglePeople Chapter 4. Non-API Google Applications 41. Don't Try This at Home 42. Building a Custom Date-Range Search Form 43. Building Google Directory URLs 44. Scraping Google Results 45. Scraping Google AdWords 46. Scraping Google Groups 47. Scraping Google News 48. Scraping Google Catalogs 49. Scraping the Google Phonebook Chapter 5. Introducing the Google Web API 50. Programming the Google Web API with Perl 51. Looping Around the 10-Result Limit 52.
    [Show full text]
  • (Pdf) of from Push/Enter to Eval/Apply by Program Transformation
    From Push/Enter to Eval/Apply by Program Transformation MaciejPir´og JeremyGibbons Department of Computer Science University of Oxford [email protected] [email protected] Push/enter and eval/apply are two calling conventions used in implementations of functional lan- guages. In this paper, we explore the following observation: when considering functions with mul- tiple arguments, the stack under the push/enter and eval/apply conventions behaves similarly to two particular implementations of the list datatype: the regular cons-list and a form of lists with lazy concatenation respectively. Along the lines of Danvy et al.’s functional correspondence between def- initional interpreters and abstract machines, we use this observation to transform an abstract machine that implements push/enter into an abstract machine that implements eval/apply. We show that our method is flexible enough to transform the push/enter Spineless Tagless G-machine (which is the semantic core of the GHC Haskell compiler) into its eval/apply variant. 1 Introduction There are two standard calling conventions used to efficiently compile curried multi-argument functions in higher-order languages: push/enter (PE) and eval/apply (EA). With the PE convention, the caller pushes the arguments on the stack, and jumps to the function body. It is the responsibility of the function to find its arguments, when they are needed, on the stack. With the EA convention, the caller first evaluates the function to a normal form, from which it can read the number and kinds of arguments the function expects, and then it calls the function body with the right arguments.
    [Show full text]
  • Name Description
    Perl version 5.10.0 documentation - perlnewmod NAME perlnewmod - preparing a new module for distribution DESCRIPTION This document gives you some suggestions about how to go about writingPerl modules, preparing them for distribution, and making them availablevia CPAN. One of the things that makes Perl really powerful is the fact that Perlhackers tend to want to share the solutions to problems they've faced,so you and I don't have to battle with the same problem again. The main way they do this is by abstracting the solution into a Perlmodule. If you don't know what one of these is, the rest of thisdocument isn't going to be much use to you. You're also missing out onan awful lot of useful code; consider having a look at perlmod, perlmodlib and perlmodinstall before coming back here. When you've found that there isn't a module available for what you'retrying to do, and you've had to write the code yourself, considerpackaging up the solution into a module and uploading it to CPAN so thatothers can benefit. Warning We're going to primarily concentrate on Perl-only modules here, ratherthan XS modules. XS modules serve a rather different purpose, andyou should consider different things before distributing them - thepopularity of the library you are gluing, the portability to otheroperating systems, and so on. However, the notes on preparing the Perlside of the module and packaging and distributing it will apply equallywell to an XS module as a pure-Perl one. What should I make into a module? You should make a module out of any code that you think is going to beuseful to others.
    [Show full text]
  • Stepping Ocaml
    Stepping OCaml TsukinoFurukawa YouyouCong KenichiAsai Ochanomizu University Tokyo, Japan {furukawa.tsukino, so.yuyu, asai}@is.ocha.ac.jp Steppers, which display all the reduction steps of a given program, are a novice-friendly tool for un- derstanding program behavior. Unfortunately, steppers are not as popular as they ought to be; indeed, the tool is only available in the pedagogical languages of the DrRacket programming environment. We present a stepper for a practical fragment of OCaml. Similarly to the DrRacket stepper, we keep track of evaluation contexts in order to reconstruct the whole program at each reduction step. The difference is that we support effectful constructs, such as exception handling and printing primitives, allowing the stepper to assist a wider range of users. In this paper, we describe the implementationof the stepper, share the feedback from our students, and show an attempt at assessing the educational impact of our stepper. 1 Introduction Programmers spend a considerable amount of time and effort on debugging. In particular, novice pro- grammers may find this process extremely painful, since existing debuggers are usually not friendly enough to beginners. To use a debugger, we have to first learn what kinds of commands are available, and figure out which would be useful for the current purpose. It would be even harder to use the com- mand in a meaningful manner: for instance, to spot the source of an unexpected behavior, we must be able to find the right places to insert breakpoints, which requires some programming experience. Then, is there any debugging tool that is accessible to first-day programmers? In our view, the algebraic stepper [1] of DrRacket, a pedagogical programming environment for the Racket language, serves as such a tool.
    [Show full text]
  • A Practical Introduction to Python Programming
    A Practical Introduction to Python Programming Brian Heinold Department of Mathematics and Computer Science Mount St. Mary’s University ii ©2012 Brian Heinold Licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported Li- cense Contents I Basics1 1 Getting Started 3 1.1 Installing Python..............................................3 1.2 IDLE......................................................3 1.3 A first program...............................................4 1.4 Typing things in...............................................5 1.5 Getting input.................................................6 1.6 Printing....................................................6 1.7 Variables...................................................7 1.8 Exercises...................................................9 2 For loops 11 2.1 Examples................................................... 11 2.2 The loop variable.............................................. 13 2.3 The range function............................................ 13 2.4 A Trickier Example............................................. 14 2.5 Exercises................................................... 15 3 Numbers 19 3.1 Integers and Decimal Numbers.................................... 19 3.2 Math Operators............................................... 19 3.3 Order of operations............................................ 21 3.4 Random numbers............................................. 21 3.5 Math functions............................................... 21 3.6 Getting
    [Show full text]
  • Making a Faster Curry with Extensional Types
    Making a Faster Curry with Extensional Types Paul Downen Simon Peyton Jones Zachary Sullivan Microsoft Research Zena M. Ariola Cambridge, UK University of Oregon [email protected] Eugene, Oregon, USA [email protected] [email protected] [email protected] Abstract 1 Introduction Curried functions apparently take one argument at a time, Consider these two function definitions: which is slow. So optimizing compilers for higher-order lan- guages invariably have some mechanism for working around f1 = λx: let z = h x x in λy:e y z currying by passing several arguments at once, as many as f = λx:λy: let z = h x x in e y z the function can handle, which is known as its arity. But 2 such mechanisms are often ad-hoc, and do not work at all in higher-order functions. We show how extensional, call- It is highly desirable for an optimizing compiler to η ex- by-name functions have the correct behavior for directly pand f1 into f2. The function f1 takes only a single argu- expressing the arity of curried functions. And these exten- ment before returning a heap-allocated function closure; sional functions can stand side-by-side with functions native then that closure must subsequently be called by passing the to practical programming languages, which do not use call- second argument. In contrast, f2 can take both arguments by-name evaluation. Integrating call-by-name with other at once, without constructing an intermediate closure, and evaluation strategies in the same intermediate language ex- this can make a huge difference to run-time performance in presses the arity of a function in its type and gives a princi- practice [Marlow and Peyton Jones 2004].
    [Show full text]
  • Scaling a Content Delivery System for Open Source Software
    Scaling a Content Delivery system for Open Source Software Niklas Edmundsson May 25, 2015 Master’s Thesis in Computing Science, 30 credits Supervisor at CS-UmU: Per-Olov Ostberg¨ Examiner: Fredrik Georgsson Ume˚a University Department of Computing Science SE-901 87 UMEA˚ SWEDEN Abstract This master’s thesis addresses scaling of content distribution sites. In a case study, the thesis investigates issues encountered on ftp.acc.umu.se,acontentdistributionsiterun by the Academic Computer Club (ACC) of Ume˚aUniversity. Thissiteischaracterized by the unusual situation of the external network connectivity having higher bandwidth than the components of the system, which differs from the norm of the external con- nectivity being the limiting factor. To address this imbalance, a caching approach is proposed to architect a system that is able to fully utilize the available network capac- ity, while still providing a homogeneous resource to the end user. A set of modifications are made to standard open source solutions to make caching perform as required, and results from production deployment of the system are evaluated. In addition, time se- ries analysis and forecasting techniques are introduced as tools to improve the system further, resulting in the implementation of a method to automatically detect bursts and handle load distribution of unusually popular files. Contents 1Introduction 1 2Background 3 3 Architecture analysis 5 3.1 Overview ................................... 5 3.2 Components . 7 3.2.1 mod cache disk largefile - Apache httpd disk cache . 8 3.2.2 libhttpcacheopen - using the httpd disk cache for otherservices. 9 3.2.3 redirprg.pl-redirectionsubsystem . ... 10 3.3 Results....................................
    [Show full text]
  • Advanced Tcl E D
    PART II I I . A d v a n c Advanced Tcl e d T c l Part II describes advanced programming techniques that support sophisticated applications. The Tcl interfaces remain simple, so you can quickly construct pow- erful applications. Chapter 10 describes eval, which lets you create Tcl programs on the fly. There are tricks with using eval correctly, and a few rules of thumb to make your life easier. Chapter 11 describes regular expressions. This is the most powerful string processing facility in Tcl. This chapter includes a cookbook of useful regular expressions. Chapter 12 describes the library and package facility used to organize your code into reusable modules. Chapter 13 describes introspection and debugging. Introspection provides information about the state of the Tcl interpreter. Chapter 14 describes namespaces that partition the global scope for vari- ables and procedures. Namespaces help you structure large Tcl applications. Chapter 15 describes the features that support Internationalization, includ- ing Unicode, other character set encodings, and message catalogs. Chapter 16 describes event-driven I/O programming. This lets you run pro- cess pipelines in the background. It is also very useful with network socket pro- gramming, which is the topic of Chapter 17. Chapter 18 describes TclHttpd, a Web server built entirely in Tcl. You can build applications on top of TclHttpd, or integrate the server into existing appli- cations to give them a web interface. TclHttpd also supports regular Web sites. Chapter 19 describes Safe-Tcl and using multiple Tcl interpreters. You can create multiple Tcl interpreters for your application. If an interpreter is safe, then you can grant it restricted functionality.
    [Show full text]
  • Proceedings YAPC::Europe 2012 .Com Perl Software Development Services Table of Contents 
    Proceedings YAPC::Europe 2012 .com Perl Software Development Services Table of contents Foreword 5 FatPacker: understanding and appreciating the insanity 6 Vorbild::Beitrag::POD 8 CGI.pm MUST DIE - Together we shall annihilate CGI.pm! 9 CPANTS: Kwalitative website and its tools 10 Designing the Internet of Things: Arduino and Perl 11 Dancing with WebSockets 12 Dancer 2 - Official status: 14 Practical Dancer: moving away from CGI 16 Bringing Perl to a Younger Generation 18 Asynchronous programming FTW! 22 Mojolicious 24 Continuous deployment with Perl 36 Array programming for mere mortals 37 Ontology Aware Applications 42 Distributed Code Review in Perl - State of the Practice 48 address-sanitizer - A fast memory error detector 52 Exceptional Perl 6 55 The joy of breaking stuff 59 Macros in Rakudo 66 Why statement modifiers can harm maintainability! 70 A discussion on how to organize a Perl Mongers group 72 Building C/C++ libraries with Perl 74 8PSMET#1*O0OMJOF"DDPNNPEBUJPO3FTFSWBUJPOTBOETUJMMHSPXJOH 8FOFFE1FSM%FWFMPQFST .Z4RM%#"T 8FVTF1FSM 1VQQFU "QBDIF 4PGUXBSF%FWFMPQFST 4ZT"ENJOT .Z42- .FNDBDIF (JU -JOVY $JTDP 8FC%FTJHOFST 'SPOU&OE%FWFMPQFST +VOJQFSBOENPSF /FUXPSL&OHJOFFSTBOENPSFw /08)*3*/( (SFBUMPDBUJPOJOUIFDFOUFSPG"NTUFSEBN $PNQFUJUJWF4BMBSZ3FMPDBUJPO1BDLBHF *OUFSOBUJPOBM SFTVMUESJWFOEZOBNJDXPSLFOWJSPONFOU *OUFSFTUFE XXXCPPLJOHDPNKPCT Foreword 5 Welcome to YAPC::Europe 2012. This is the fourteenth European Perl conference! The Frankfurt 8PSMET#1*O0OMJOF"DDPNNPEBUJPO3FTFSWBUJPOTBOETUJMMHSPXJOH Perlmongers have great pleasure in hosting this event this year. We‘d like to welcome you here in Frankfurt. The city that is now the heart of the Perl community for at least days. We have attendees from more than 40 countries all over the world, so there is a rich mix of different cultures and different people.
    [Show full text]