1
|
- Session 2
- INFM 718N
- Web-Enabled Databases
|
2
|
- Programming
- PHP
- Idea Rally (40 minutes)
- Programming well
|
3
|
|
4
|
- 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
|
5
|
|
6
|
- Learn some words
- Put those words together in simple ways
- Examine to broaden your understanding
- Create to deepen your mastery
- Repeat until fluent
|
7
|
- Local vs. Web-server-based display
- HTML as an indirect display mechanism
- “View Source” for debugging
- Procedural perspective (vs. object-oriented)
|
8
|
- ----- HTML stuff -----
- <?php
- ----- PHP stuff -----
- ?>
- ----- HTML stuff -----
- http://---URL stuff---/xxxxx.php
|
9
|
- 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
|
10
|
- Arithmetic operators
- Logical operators
- < <=3D =3D=3D !=3D >=3D > && || !
- String operator
|
11
|
- Sequential
- {…; …;…;}
- Semicolons are required at the end of every statement
- Conditional
- if (3=3D=3Di) {…} else {…}
- Loop
- foreach ($array as $key =3D> $value) {…}
- while ($row=3Dmysql_fetch_array(…)) {…}
- For ($i=3D0; $i<10; $i++) {…}
- Braces are optional around a single statement
|
12
|
- A set of key-element pairs
- $days =3D array(“Jan”->31, “Feb”=3D>2=
8,
…);
- $months =3D explode(“/”,
“Jan/Feb/Mar/…/Dec”);
- $_POST
- Each element is accessed by the key
- {$days[“Jan”]}
- $months[0];
- Arrays and loops work naturally together
|
13
|
- Naturally encodes an order among elements
- 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
|
14
|
- Declaration
- function multiply($a, $b=3D3){return $a*$b;}
- Invoking a method
- All variables in a function have only local scope
- Unless declared as global in the function
|
15
|
- Limit complexity
- Extent
- Interaction
- Abstraction
- Minimize duplication
|
16
|
- <form action=3D“formResponseDemo.php”,
method=3D“post”>
- email: <input type=3D“text”, name=3D“emailR=
21;, value=3D“<?php
echo $email ?>”, size=3D30 />
- <input type=3D“radio”, name=3D“sure”,
value=3D“yes” /> Yes
- <input type=3D“radio”, name=3D“sure”,
value=3D“no” /> No
- <input type=3D“submit”, name=3D“submit”,
value=3D“Submit” />
- <input type=3D“hidden”, name=3D“submitted̶=
1;,
value=3D“TRUE” />
- </form>
- if (isset($_POST[“submitted”])) {
- echo “Your email address is $email.”;
- } else {
- echo “Error: page reached without proper form submission!R=
21;;
- }
|
17
|
- 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
- Modularity
|
18
|
- 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
|
19
|
- 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
|
20
|
- Functionality
- Content
- Usability
- Security/Stability
|
21
|
- Attributes
- Appearance
- Concepts (represented by data)
- Behavior
- What it does
- How you control it
- How you observe the results
|
22
|
- 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)
|
23
|
- 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
|
24
|
- 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
|
25
|
- Reusing code [run the book’s programs]
- Understanding patterns [read the book]
- Applying patterns [modify programs]
- Coding without patterns [programming]
- Recognizing new patterns
|
26
|
- Design before you build
- Focus your learning
- Program defensively
- Limit complexity
- Debug syntax from the top down
|
27
|
|
28
|
- 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
|
29
|
- 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
|
30
|
- 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
|
31
|
- Syntax errors
- 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)
|
32
|
- Focus on the first error message
- 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
|
33
|
- 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!
|
34
|
- 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
|
35
|
- 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
|
36
|
- First, look where the bad data was created
- If that fails, print variables at key locations
- if (DEBUG) echo “\$foobar =3D $foobar”;
- Examine output for unexpected patterns
- Once found, proceed as for run time errors
- define (“DEBUG”, FALSE); to clean the output
|
37
|
- Functional decomposition
- High-level languages
- Structured programming, object-oriented design
- Patterns
- Design patterns, standard algorithms, code reuse
|
38
|
- What was the muddiest point in today’s class?
- Be brief!
- No names!
|