PHP Programming
Session 2
INFM 718N
Web-Enabled Databases
Agenda
•	Programming

•	PHP

•	Idea Rally (40 minutes)

•	Programming well

Software
•	Software represents an aspect of reality
–	Input and output represent the state of the world
–	Software describes how the two are related

•	Programming languages specify the model
–	Data structures model things
–	Structured programming models actions
–	Object-oriented programming links the two

•	A development process organizes the effort
The Big Picture
Language Learning
•	Learn some words

•	Put those words together in simple ways

•	Examine to broaden your understanding

•	Create to deepen your mastery

•	Repeat until fluent
Thinking About PHP
•	Local vs. Web-server-based display

•	HTML as an indirect display mechanism

•	“View Source” for debugging

•	Procedural perspective (vs. object-oriented)
Making PHP
----- HTML stuff -----
<?php
	----- PHP stuff -----
?>
----- HTML stuff -----

http://---URL stuff---/xxxxx.php
Variables
•	Name starts with a $
–	Case sensitive (assume everything could be!)

•	Hold a value
–	Number (integer, float)
–	String (double quotes, \ escape character)
–	TRUE, FLASE
–	NULL

•	Need not be declared, automatically cast
Operators in PHP
•	Arithmetic operators
+  -  *  / 

•	Logical operators
<  <=  ==  !=  >=  >  &&  ||  !

•	String operator
.
Statements in PHP
•	Sequential
{…; …;…;}
Semicolons are required at the end of every statement
•	Conditional
if (3==i) {…} else {…}
•	Loop 
foreach ($array as $key => $value) {…} 
while ($row=mysql_fetch_array(…)) {…}
For ($i=0; $i<10; $i++) {…}
•	Braces are optional around a single statement
Arrays in PHP
•	A set of key-element pairs
$days = array(“Jan”->31, “Feb”=>28, …);
$months = explode(“/”, “Jan/Feb/Mar/…/Dec”);
$_POST

•	Each element is accessed by the key
–	{$days[“Jan”]}
–	$months[0];

•	Arrays and loops work naturally together
Thinking about Arrays
•	Naturally encodes an order among elements
–	$days = rksort($days);

•	Natural data structure to use with a loop
–	Do the same thing to different data

•	PHP unifies arrays and hashtables
–	Elements may be different types
Functions in PHP
•	Declaration
function multiply($a, $b=3){return $a*$b;}

•	Invoking a method
$b = multiply($b, 7);

•	All variables in a function have only local scope
•	Unless declared as global in the function

Why Modularity?
•	Limit complexity
–	Extent
–	Interaction
–	Abstraction

•	Minimize duplication

Using PHP with (X)HTML Forms
<form action=“formResponseDemo.php”, method=“post”>
	email: <input type=“text”, name=“email”, value=“<?php echo $email ?>”, size=30 />
	<input type=“radio”, name=“sure”, value=“yes” /> Yes
	<input type=“radio”, name=“sure”, value=“no” /> No
	<input type=“submit”, name=“submit”, value=“Submit” />
	<input type=“hidden”, name=“submitted”, value=“TRUE” />
</form>

if (isset($_POST[“submitted”])) {
	echo “Your email address is $email.”;
} else {
	echo “Error: page reached without proper form submission!”;
}
Sources of Complexity
•	Syntax
–	Learn to read past the syntax to see the ideas
–	Copy working examples to get the same effect

•	Interaction of data and control structures
–	Structured programming

•	Modularity
Some Things to Pay Attention To
Syntax
•	How layout helps reading
•	How variables are named
•	How strings are used
•	How input is obtained
•	How output is created

Structured Programming
•	How things are nested
•	How arrays are used
Modular Programming
•	Functional decomposition
•	How functions are invoked
•	How arguments work
•	How scope is managed
•	How errors are handled
•	How results are passed
The “Idea Rally”
•	A 90-second “elevator pitch”
–	One interesting and feasible idea
–	Plus why they should want you on their team!
–	Showing one optional powerpoint slide
•	Illustrate your point, don’t say the same words!
•	One-page handout (22 copies)
–	Your idea in a short paragraph
–	Your name, picture and contact information
–	A list of your strengths
First Things First
•	Functionality

•	Content

•	Usability

•	Security/Stability
What are Requirements?
•	Attributes
–	Appearance
–	Concepts (represented by data)

•	Behavior
–	What it does
–	How you control it
–	How you observe the results
Who Sets the Requirements?
•	People who need the task done (customers)

•	People that will operate the system (users)

•	People who use the system’s outputs

•	People who provide the system’s inputs

•	Whoever pays for it (requirements commissioner)
The Requirements Interview
•	Focus the discussion on the task
–	Look for entities that are mentioned
•	Discuss the system’s most important effects
–	Displays, reports, data storage
–	Learn where the system’s inputs come from
–	People, stored data, devices, …  
•	Note any data that is mentioned
–	Try to understand the structure of the data
•	Shoot for the big picture, not every detail
The Project Plan
•	One-page contract
–	Between developer and requirements commissioner

•	Goal 	The problem to be solved
•	Product	What you plan to deliver
•	Scope	Available time and personnel
•	Roles	What you expect each other to do
Programming Skills Hierarchy
•	Reusing code [run the book’s programs]

•	Understanding patterns [read the book]

•	Applying patterns [modify programs]

•	Coding without patterns [programming]

•	Recognizing new patterns
Best Practices
•	Design before you build

•	Focus your learning

•	Program defensively

•	Limit complexity

•	Debug syntax from the top down
Rapid Prototyping + Waterfall
Focus Your Learning 
•	Find examples that work
–	Tutorials, articles, examples

•	Cut them down to focus on what you need
–	Easiest to learn with throwaway programs

•	Once it works, include it in your program
–	If it fails, you have a working example to look at
Defensive Programming
•	Goal of software is to create desired output

•	Programs transform input into output
–	Some inputs may yield undesired output

•	Methods should enforce input assumptions
–	Guards against the user and the programmer!

•	Everything should be done inside methods
Limiting Complexity
•	Single errors are usually easy to fix
–	So avoid introducing multiple errors

•	Start with something that works
–	Start with an existing program if possible
–	If starting from scratch, start small

•	Add one new feature
–	Preferably isolated in its own method
Types of Errors
•	Syntax errors
–	Detected at compile time

•	Run time exceptions
–	Cause system-detected failures at run time

•	Logic errors
–	Cause unanticipated behavior (detected by you!)

•	Design errors
–	Fail to meet the need (detected by stakeholders)
Debugging Syntax Errors
•	Focus on the first error message
–	Fix one thing at a time

•	The line number is where it was detected
–	It may have been caused much earlier

•	Understand the cause of “warnings”
–	They may give a clue about later errors

•	If all else fails, comment out large code regions
–	If it compiles, the error is in the commented part
Run Time Exceptions
•	Occur when you try to do the impossible
–	Use a null variable, divide by zero, …

•	The cause is almost never where the error is
–	Why is the variable null?

•	Exceptions often indicate a logic error
–	Find why it happened, not just a quick fix!
Debugging Run-Time Exceptions
•	Run the program to get a stack trace
–	Where was this function called from?

•	Print variable values before the failure

•	Reason backwards to find the cause
–	Why do they have these values?

•	If necessary, print some values further back
Logic Errors
•	Evidenced by inappropriate behavior

•	Can’t be automatically detected
–	“Inappropriate” is subjective

•	Sometimes very hard to detect
–	Sometimes dependent on user behavior
–	Sometimes (apparently) random

•	Cause can be hard to pin down
Debugging Logic Errors
•	First, look where the bad data was created

•	If that fails, print variables at key locations
–	if (DEBUG) echo “\$foobar = $foobar”;

•	Examine output for unexpected patterns

•	Once found, proceed as for run time errors
–	define (“DEBUG”, FALSE); to clean the output
Three Big Ideas
•	Functional decomposition
–	Outside-in design

•	High-level languages
–	Structured programming, object-oriented design

•	Patterns
–	Design patterns, standard algorithms, code reuse
One-Minute Paper
What was the muddiest point in today’s class?

•	Be brief!
•	No names!