DOCSLIB.ORG

Ps1-Mops Source Code Documentation

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Ps1-Mops Source Code Documentation PS1-MOPS SOURCE CODE DOCUMENTATION DRAFT D. Chang Institute for Astronomy University of Hawaii at Manoa An overview of using Doxygen to processed embedded documentation in PS1-MOPS Perl source code is provided. The goal is to be able to automatically generate documentation at the program/class-level and the subroutine-level. This may be accomplished using Doxygen and a filter specific to Perl as Doxygen does not natively support Perl. Example documented source code is provided along with actual Doxygen-generated HTML output. INTRODUCTION This document provides an overview of using of Doxygen [1] for PS1-MOPS Perl source code. Doxygen does not have native support for Perl. However, it may be used to generate documentation from Perl code if the code is first preprocessed so that Doxygen-compatible input is produced. This is accomplished using a filter [2]. The source code may then contain commands that are analogues to Doxygen commands to produce an equivalent level of documentation from comments embedded in Perl source code. The initial benefit of this documentation creation method is a hyperlinked HTML API reference containing both module-level and subroutine-level documentation. The scope of this generated documentation is intended to span the range from the user-level to the programmer-level with an emphasis on documentation to support code maintenance and development. One of the most common documentation systems in use with Perl is POD (plain old documentation). The guidelines for Doxygen-compatible documentation are derived in large part from conventional implementations of POD. Use of Doxygen is intended to provide the same usability as POD but augmented by the added flexibility of Doxygen. The purpose is to develop a general method of documentation that applies to all aspects of PS1-MOPS programming. This is made possible by Doxygen. PROGRAMMING ELEMENTS Source code follows the hierarchy of namespace, class, and subroutine. In Perl, namespaces are indicated by the directories that contain modules. Classes are, in general, the same as modules. Modules may also be called packages. Subroutines consist of either functions or object methods. These programming elements are common to all object-oriented programming languages. COMPARISON WITH POD Perl modules are often documented using POD format. Advantages of POD include programmer familiarity due to its ubiquity, usability with established tools such as perldoc, and overall simplicity in its implementation. While POD does not mandate a set of categories for which to include documentation, a number of common ones that are often addressed are listed below. For documentation of MOPS source code, it is suggested that embedded documentation cover the categories listed below thereby providing equal utility with conventional POD documentation. • NAME The name of the module that typically includes a brief description separated from the name by three characters: space, dash, space. • SYNOPSIS Includes examples of usage. • DESCRIPTION A detailed description of the module. • FUNCTIONS Subroutines that are not specific class methods. • METHODS Subroutines that are implemented by a specific class/object. WRITING DOXYGEN-COMPATIBLE DOCUMENTATION IN PERL Doxygen does not natively support documentation in source code comments in Perl. However, Perl code documentation may be parsed by Doxygen by preprocessing the Perl code through a filter. The filter result, being in Doxygen-format, can then be parsed by Doxygen. The source code must contain commands recognizable by the filter. These commands, and how to format Perl code documentation so that is compatible with a Doxygen filter, are described henceforth. PROGRAM/CLASS-LEVEL DOCUMENTATION Classes generally correspond to individual Perl modules. Executable Perl scripts are considered to be independent programs. Program/class-level documentation in the source code mostly corresponds to the kind of documentation that might be found in a manual page. It is intended to provide an overview of the class along with usage examples. The following list describes Doxygen filter commands for program/class-level documentation. Doxygen filter commands • ## @file Corresponds to Doxygen command \file. Used to describe the contents of a file. The filename should be listed here along with a brief description followed by a detailed description. This section maybe used to provide the POD content found under the headings: NAME, SYNOPSIS, and DESCRIPTION. • ## @class Corresponds to Doxygen command \class. Used to describe a class. The class name along with a detailed description should be defined here. Note that the classes specified using the @class command is the only way for Doxygen to identify classes. It is important that they be specified. • # @par Paragraphs may be created using the @par command. Note the @par command is preceded by a single hash mark. Text on the same line as the @par command will print as a header in the output. PS1-MOPS Source Code Documentation 2 • # @note Text notated as note text. • # @see Provide comma-separated list of references to other items of relevance. SUBROUTINE-LEVEL DOCUMENTATION Subroutines include both functions and methods. This level of documentation is intended to be comprehensive. Every function and method should include a basic set of documentation. Each subroutine name may be preceded with its access scope. Available scopes are public, private, and protected. Undefined scopes default to public. The primary set of Doxygen filter commands is listed below. Doxygen filter commands • ## @fn Corresponds to Doxygen command \fn. Used to describe a function including its parameters and return value. • ## @method Used to describe an object method. • ## @cmethod Used to describe a class method. • # @param Describe a parameter to a function. • # @return Describe the return value for a function/method. VERSIONS Software versions are an essential documentation component. Versioning will be managed by CVS using the CVS tag $Revision: $. For Perl, the conventional $VERSION variable will be used. Many popular Perl programs, such as ExtUtils::MakeMaker or Module::Build, make use of this variable to determine module versions. To obtain a standard version number for Perl modules, typically having extension .pm, the following code [3] should be included in each module. our $VERSION = sprintf "%d.%d", q$Revision: $ =~ /(\d+)/g; When this code is committed to CVS, the version number will be placed after Revision:. For example, given a CVS revision of 1.1 the result in the source code will be our $VERSION = sprintf "%d.%d", q$Revision: 1.1$ =~ /(\d+)/g; When the module version needs to be referenced, it can be obtained using the following code. use module_name; $module_version = $module_name::VERSION; The variable $module_version will have the value 1.1. Perl executables, typically having extension .pl, cannot be imported using use, though they can be imported using require but this causes them to be executed which is generally not wanted. Therefore, an alternative method of version number retrieval will be used. Perl executable code should still contain the our $VERSION line defined previously. To make the CVS revision number available, executables should implement the command-line option --version so that the following statement will correctly retrieve the CVS revision number defined in the source code. PS1-MOPS Source Code Documentation 3 $ executable_name.pl --version USING DOXYGEN Use of Doxygen with Perl requires two files: a configuration file (doxy-config) and a filter configuration file (perl-doxy-config). The configuration files define the location of the source code to be processed along with the destination of the output. They also define various features of the output. The intention of using Doxygen with MOPS is to generate an HTML API reference. To specify a filter to be used by Doxygen, configure the following option: INPUT_FILTER = doxygenfilter Once the configuration files have proper definitions, Doxygen may be executed via the command-line using: $ doxygen perl-doxy-config DOXYGEN HTML DOCUMENTATION FEATURES Some of the features present in Doxygen-generated HTML documentation are listed below. File list Contains all the files parsed by Doxygen. The files to be included are denoted by a pattern in the Perl Doxygen configuration file. Class list Only those items notated by @class will be included in this category. Source code Doxygen provides for viewing partially colorized source code directly in the HTML API reference. Formatted descriptions Formatting includes lists and emphasized text along with paragraphs and paragraph titles. Program/class-level descriptions are referenced through Doxygen file references found in the File list. Function/method documentation Information includes access scope, a description, parameters, and return values. Functions/methods are grouped by access scope. AUTOMATIC DOCUMENTATION GENERATION The presence of properly formatted source code documentation allows for the automatic generation of a documentation set for the code. To facilitate current documentation for the MOPS code base, documentation will be extracted, formatted and updated on a nightly basis. FUTURE WORK Doxygen has an extensive feature set and can serve extended purposes beyond those described herein. Some additional areas of documentation development are listed below. • Automatically determine missing documentation items for source code. • Tweak filter so that embedded commands have greater consistency in formatting.
Load more

Recommended publications
  • Executable Code Is Not the Proper Subject of Copyright Law a Retrospective Criticism of Technical and Legal Naivete in the Apple V
    Executable Code is Not the Proper Subject of Copyright Law A retrospective criticism of technical and legal naivete in the Apple V. Franklin case Matthew M. Swann, Clark S. Turner, Ph.D., Department of Computer Science Cal Poly State University November 18, 2004 Abstract: Copyright was created by government for a purpose. Its purpose was to be an incentive to produce and disseminate new and useful knowledge to society. Source code is written to express its underlying ideas and is clearly included as a copyrightable artifact. However, since Apple v. Franklin, copyright has been extended to protect an opaque software executable that does not express its underlying ideas. Common commercial practice involves keeping the source code secret, hiding any innovative ideas expressed there, while copyrighting the executable, where the underlying ideas are not exposed. By examining copyright’s historical heritage we can determine whether software copyright for an opaque artifact upholds the bargain between authors and society as intended by our Founding Fathers. This paper first describes the origins of copyright, the nature of software, and the unique problems involved. It then determines whether current copyright protection for the opaque executable realizes the economic model underpinning copyright law. Having found the current legal interpretation insufficient to protect software without compromising its principles, we suggest new legislation which would respect the philosophy on which copyright in this nation was founded. Table of Contents INTRODUCTION................................................................................................. 1 THE ORIGIN OF COPYRIGHT ........................................................................... 1 The Idea is Born 1 A New Beginning 2 The Social Bargain 3 Copyright and the Constitution 4 THE BASICS OF SOFTWARE ..........................................................................
    [Show full text]
  • Studying the Real World Today's Topics
    Studying the real world Today's topics Free and open source software (FOSS) What is it, who uses it, history Making the most of other people's software Learning from, using, and contributing Learning about your own system Using tools to understand software without source Free and open source software Access to source code Free = freedom to use, modify, copy Some potential benefits Can build for different platforms and needs Development driven by community Different perspectives and ideas More people looking at the code for bugs/security issues Structure Volunteers, sponsored by companies Generally anyone can propose ideas and submit code Different structures in charge of what features/code gets in Free and open source software Tons of FOSS out there Nearly everything on myth Desktop applications (Firefox, Chromium, LibreOffice) Programming tools (compilers, libraries, IDEs) Servers (Apache web server, MySQL) Many companies contribute to FOSS Android core Apple Darwin Microsoft .NET A brief history of FOSS 1960s: Software distributed with hardware Source included, users could fix bugs 1970s: Start of software licensing 1974: Software is copyrightable 1975: First license for UNIX sold 1980s: Popularity of closed-source software Software valued independent of hardware Richard Stallman Started the free software movement (1983) The GNU project GNU = GNU's Not Unix An operating system with unix-like interface GNU General Public License Free software: users have access to source, can modify and redistribute Must share modifications under same
    [Show full text]
  • Chapter 1 Introduction to Computers, Programs, and Java
    Chapter 1 Introduction to Computers, Programs, and Java 1.1 Introduction • The central theme of this book is to learn how to solve problems by writing a program . • This book teaches you how to create programs by using the Java programming languages . • Java is the Internet program language • Why Java? The answer is that Java enables user to deploy applications on the Internet for servers , desktop computers , and small hand-held devices . 1.2 What is a Computer? • A computer is an electronic device that stores and processes data. • A computer includes both hardware and software. o Hardware is the physical aspect of the computer that can be seen. o Software is the invisible instructions that control the hardware and make it work. • Computer programming consists of writing instructions for computers to perform. • A computer consists of the following hardware components o CPU (Central Processing Unit) o Memory (Main memory) o Storage Devices (hard disk, floppy disk, CDs) o Input/Output devices (monitor, printer, keyboard, mouse) o Communication devices (Modem, NIC (Network Interface Card)). Bus Storage Communication Input Output Memory CPU Devices Devices Devices Devices e.g., Disk, CD, e.g., Modem, e.g., Keyboard, e.g., Monitor, and Tape and NIC Mouse Printer FIGURE 1.1 A computer consists of a CPU, memory, Hard disk, floppy disk, monitor, printer, and communication devices. CMPS161 Class Notes (Chap 01) Page 1 / 15 Kuo-pao Yang 1.2.1 Central Processing Unit (CPU) • The central processing unit (CPU) is the brain of a computer. • It retrieves instructions from memory and executes them.
    [Show full text]
  • Some Preliminary Implications of WTO Source Code Proposala INTRODUCTION
    Some preliminary implications of WTO source code proposala INTRODUCTION ............................................................................................................................................... 1 HOW THIS IS TRIMS+ ....................................................................................................................................... 3 HOW THIS IS TRIPS+ ......................................................................................................................................... 3 WHY GOVERNMENTS MAY REQUIRE TRANSFER OF SOURCE CODE .................................................................. 4 TECHNOLOGY TRANSFER ........................................................................................................................................... 4 AS A REMEDY FOR ANTICOMPETITIVE CONDUCT ............................................................................................................. 4 TAX LAW ............................................................................................................................................................... 5 IN GOVERNMENT PROCUREMENT ................................................................................................................................ 5 WHY GOVERNMENTS MAY REQUIRE ACCESS TO SOURCE CODE ...................................................................... 5 COMPETITION LAW .................................................................................................................................................
    [Show full text]
  • Java Code Documentation Example
    Java Code Documentation Example Fruitless Martino sometimes quick-freeze his peritonitis hugely and night-club so dispraisingly! Glottogonic and sublinear Finn melt his bodice permeates podding benevolently. Oswald usually medicines surgically or orbs telescopically when polyunsaturated Hugh dement evidentially and lewdly. The javadoc itself an unsupported extension and is also important in the description for code documentation comment merely repeats the banner section DocsapijavanetURLhtmlgetAuthority-- a method getAuhority in the. API reference code comments Google Developers. Omitting many times classes being documented type, and java example of each field, all trademarks and description below code completion window, which we used to. Java Programming Style Guide. The keyboard shortcut to comment multiple in Windows is shift alt A. 10 Best Practices to multiple While Writing Code Javarevisited. Concise presentations of java programming practices tasks and conventions amply illustrated with syntax highlighted code examples. Java Documentation Comments Tutorialspoint. Java Programming Guidelines. If this tag easily comment related comments java code, this user to new field in the dependency. The following examples demonstrate a pain line summary followed by detailed documentation in song three. CS 302 Commenting Guide Program Commenting Guide File. For sober you spawn use author tag to identify the author of a. Opinions expressed by the code example code documentation is overridden in the documentation for example code base classes and decide to allow bikes to achieve these methods. Example slope from the Javadoc documentation code can be documented inline Single Line comments are started by each may be positioned after a. The Documentation Comment Specification permits leading asterisks on enough first.
    [Show full text]
  • [PDF] Beginning Raku
    Beginning Raku Arne Sommer Version 1.00, 22.12.2019 Table of Contents Introduction. 1 The Little Print . 1 Reading Tips . 2 Content . 3 1. About Raku. 5 1.1. Rakudo. 5 1.2. Running Raku in the browser . 6 1.3. REPL. 6 1.4. One Liners . 8 1.5. Running Programs . 9 1.6. Error messages . 9 1.7. use v6. 10 1.8. Documentation . 10 1.9. More Information. 13 1.10. Speed . 13 2. Variables, Operators, Values and Procedures. 15 2.1. Output with say and print . 15 2.2. Variables . 15 2.3. Comments. 17 2.4. Non-destructive operators . 18 2.5. Numerical Operators . 19 2.6. Operator Precedence . 20 2.7. Values . 22 2.8. Variable Names . 24 2.9. constant. 26 2.10. Sigilless variables . 26 2.11. True and False. 27 2.12. // . 29 3. The Type System. 31 3.1. Strong Typing . 31 3.2. ^mro (Method Resolution Order) . 33 3.3. Everything is an Object . 34 3.4. Special Values . 36 3.5. :D (Defined Adverb) . 38 3.6. Type Conversion . 39 3.7. Comparison Operators . 42 4. Control Flow . 47 4.1. Blocks. 47 4.2. Ranges (A Short Introduction). 47 4.3. loop . 48 4.4. for . 49 4.5. Infinite Loops. 53 4.6. while . 53 4.7. until . 54 4.8. repeat while . 55 4.9. repeat until. 55 4.10. Loop Summary . 56 4.11. if . ..
    [Show full text]
  • Opportunities and Open Problems for Static and Dynamic Program Analysis Mark Harman∗, Peter O’Hearn∗ ∗Facebook London and University College London, UK
    1 From Start-ups to Scale-ups: Opportunities and Open Problems for Static and Dynamic Program Analysis Mark Harman∗, Peter O’Hearn∗ ∗Facebook London and University College London, UK Abstract—This paper1 describes some of the challenges and research questions that target the most productive intersection opportunities when deploying static and dynamic analysis at we have yet witnessed: that between exciting, intellectually scale, drawing on the authors’ experience with the Infer and challenging science, and real-world deployment impact. Sapienz Technologies at Facebook, each of which started life as a research-led start-up that was subsequently deployed at scale, Many industrialists have perhaps tended to regard it unlikely impacting billions of people worldwide. that much academic work will prove relevant to their most The paper identifies open problems that have yet to receive pressing industrial concerns. On the other hand, it is not significant attention from the scientific community, yet which uncommon for academic and scientific researchers to believe have potential for profound real world impact, formulating these that most of the problems faced by industrialists are either as research questions that, we believe, are ripe for exploration and that would make excellent topics for research projects. boring, tedious or scientifically uninteresting. This sociological phenomenon has led to a great deal of miscommunication between the academic and industrial sectors. I. INTRODUCTION We hope that we can make a small contribution by focusing on the intersection of challenging and interesting scientific How do we transition research on static and dynamic problems with pressing industrial deployment needs. Our aim analysis techniques from the testing and verification research is to move the debate beyond relatively unhelpful observations communities to industrial practice? Many have asked this we have typically encountered in, for example, conference question, and others related to it.
    [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]
  • Comments and Documentation 2501ICT/7421Ictnathan
    C Comments Using Doxygen Comments and Documentation 2501ICT/7421ICTNathan René Hexel School of Information and Communication Technology Griffith University Semester 1, 2012 René Hexel Comments and Documentation C Comments Using Doxygen Outline 1 C Comments 2 Using Doxygen René Hexel Comments and Documentation C Comments Using Doxygen Comments Plain C allows comments between /* and */ /* this is a valid C comment */ Comments may not be nested /* this /* is not a valid C comment */ */ C99 also allows double-slash // end-of-line comments // this is a valid comment no closing sequence needed – the comment ends at the end of the line René Hexel Comments and Documentation C Comments Using Doxygen Comment Example Example (Program with Comments) /* * This program prints "j = 007". * It does not take any parameters and returns 0 on success. */ int main(void)/ * main function definition */ { int j; // our int variable to play with j=7; // assign a value to be printed printf("j = %03.3dnn",j); // print value with leading zeroes return 0; // everything is fine, exit program } René Hexel Comments and Documentation C Comments Using Doxygen Where to put comments? At the beginning of each file (module) describe the name of the module, purpose, author, and dates when first created and last modified Before each function (method) describe the purpose of the function or method, input parameters (arguments), return values (output parameters), and pre- and postconditions (contract) At the beginning of each class describe the purpose of the class, and things to
    [Show full text]
  • Dragonfly.Wpi.Edu/Book/ February 28, 2013 8:8 Computer Science Education Paper
    February 28, 2013 8:8 Computer Science Education paper Computer Science Education Vol. XX, No. XX, June 2013, 1–18 RESEARCH ARTICLE Dragonfly – Strengthening Programming Skills by Building a Game Engine from Scratch Mark Claypool Computer Science and Interactive Media & Game Development Worcester Polytechnic Institute, Worcester, MA 01609, USA email: [email protected] (Received 00 Month 200x; final version received 00 Month 200x) Computer game development has been shown to be an effective hook for motivating students to learn both introductory and advanced computer science topics. While games can be made from scratch, to simplify the programming required game development often uses game engines that handle complicated or frequently used components of the game. These game engines present the opportunity to strengthen programming skills and expose students to a range of fundamental computer science topics. While educational efforts have been effective in using game engines to improve computer science education, there have been no published papers describing and evaluating students building a game engine from scratch as part of their course work. This paper presents the Dragonfly-approach in which students build a fully functional game engine from scratch and make a game using their engine as part of a junior-level course. Details on the programming projects are presented, as well as an evaluation of the results from two offerings that used Dragonfly. Student performance on the projects as well as student assessments demonstrate the efficacy of having students build a game engine from scratch in strengthening their programming skills. Keywords: game engine, programming, object-oriented design, software engineering, game development 1 Introduction By the end of their second year, most computer science students have been exposed to a breadth of foundational materials, such as introductory programming, basic data structures and algo- rithms, and have begun to write programs of moderate size – hundreds of lines of code, perhaps up to even a thousand lines of code.
    [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]
  • PHP Beyond the Web Shell Scripts, Desktop Software, System Daemons and More
    PHP Beyond the web Shell scripts, desktop software, system daemons and more Rob Aley This book is for sale at http://leanpub.com/php This version was published on 2013-11-25 This is a Leanpub book. Leanpub empowers authors and publishers with the Lean Publishing process. Lean Publishing is the act of publishing an in-progress ebook using lightweight tools and many iterations to get reader feedback, pivot until you have the right book and build traction once you do. ©2012 - 2013 Rob Aley Tweet This Book! Please help Rob Aley by spreading the word about this book on Twitter! The suggested hashtag for this book is #phpbeyondtheweb. Find out what other people are saying about the book by clicking on this link to search for this hashtag on Twitter: https://twitter.com/search?q=#phpbeyondtheweb Contents Welcome ............................................ i About the author ...................................... i Acknowledgements ..................................... ii 1 Introduction ........................................ 1 1.1 “Use PHP? We’re not building a website, you know!”. ............... 1 1.2 Are you new to PHP? ................................. 2 1.3 Reader prerequisites. Or, what this book isn’t .................... 3 1.4 An important note for Windows and Mac users ................... 3 1.5 About the sample code ................................ 4 1.6 External resources ................................... 4 1.7 Book formats/versions available, and access to updates ............... 5 1.8 English. The Real English. .............................. 5 2 Getting away from the Web - the basics ......................... 6 2.1 PHP without a web server .............................. 6 2.2 PHP versions - what’s yours? ............................. 7 2.3 A few good reasons NOT to do it in PHP ...................... 8 2.4 Thinking about security ...............................
    [Show full text]