LIBR 246-10
Information Technology Tools and Applications - Advanced
Summer 2007 Greensheet
Steve Perry
E-mail
| Greensheet Links Textbooks and Readings Course Requirements |
Course Links
Class Web Site Instructor Information |
Resources SLIS eBookstore |
This class does not use Blackboard! The class Web site is found at: http://profperry.com/sjsu
Course Description
This course is an introduction to using PHP to build dynamic Web pages,
that is, Web page that automatically change according to a user's input
or information on a database. We will be reading from the required text
and doing programming exercises. The assignments will be problems that
you will solve by coding PHP pages that exercise the concepts learned to
date. Additionally, you will learn the fundamentals of MySQL.
Prerequisites: LIBR 202
Course Objectives
Student Learning Objectives
At the conclusion of the course the students are expected to:
- Understand the basic syntax of coding PHP programs.
- Know how use HTML forms with PHP.
- Be able to use standard PHP functions and be able to write your own custom functions;
- Understand the basics of MySQL and be able to use it in a PHP program.
- Build and maintain a small Web application.
LIBR 246 supports the following SLIS Core Competencies:
- design, query and evaluate information retrieval systems;
- demonstrate proficiency in the use of current information and communication technologies, and other related technologies, as they affect the resources and uses of libraries and other types of information providing entities;
- understand the system of standards and methods used to control and create information structures and apply basic principles involved in the organization and representation of knowledge.
Required Text and Readings
Required Text
PHP and MySQL Web Development
Welling and Thomson
Publisher: Sams; 3rd edition (2005) or later
ISBN: 0-672-32672-8
Optional Book
Visual QuickStart Guide (3rd Edition)
by Larry Ullman
Publisher: Peachpit Press; 2 edition (March 2007) or later
ISBN: 0321442490
Go to SLIS e-Bookstore.
Required Reading
You are required to read all of the text pages that I have posted in
each Learning Object, such as the Instructor Comments and the Assignments.
You need to read any of the required reading specified for your books.
I may post information on these pages that is not found in the book, but may be required for you to complete some of the assignments. In fact, I often do a fair amount of "teaching" in the assignment descriptions themselves. The assignments are where I tend to offer information based on my many years of experience working in Information Technology.
NOTE: The comments I provide for each chapter are not intended to replicate everything you can read in the books. The book is the primary "dispenser of information". As an Instructor, I supplement this by answering your questions, providing additional information, helping with class exercises/assignments, trying to steer you away from unnecessary problems, and emphasizing key points I want you to remember.
Course Requirements
Contacting the Instructor
I check my email account at least once per day, Monday-Friday, usually in
the daytime. I generally do not check for emails on Saturday, Sunday,
and Holidays.
Emergency email: sperry@palomar.edu
(Use only if no reply received within 48 hours from my regular email)
Important Dates
Semester: Summer 2007 (2007/06/04 through 2007/08/06)
Class No: 30434
The FINAL DATE of this class is 2007/08/06
No assignments or exams will be accepted after that date!
Participation
To be considered actively participating in this class, you MUST logon at
least once per week. A week is measured from Monday-Sunday. Any
student who misses two full weeks may be dropped from the class.
Important: If you have not logged on and answered the first two assigment questions (first assignment due) by the end of the third week of class, I will administratively drop you from the class as a "no show". I will not reinstate anyone to the class who has been dropped in this manner.
It is still your responsibility to make sure that you withdraw from the class, by the official withdraw date found on the college Web site, if you want to receive a grade of "W".
Communication
Sending your questions via email is the way to get help with the course
material. At a minimum, I check and respond to my emails at least once
per day Monday-Friday.
Please do not hesitate to contact me via email. Some students feel they are imposing on me by asking questions, but that's what I'm here for!
In fact, it's better to email more frequently with a question or two, than to wait until you are completely frustrated and send me 10 questions in a panic.
I teach from 5-8 different classes a semester at multiple colleges. When you send me an email, please identify yourself by first and last name, what class you are in, and what college you are attending.
Most times I will wait for you to contact me with a question before you hear from me directly. However, if I notice you are getting behind in the class, or struggling in some way, I may contact you first to see if there is anything I can do to help.
On rare occasions, I may suggest a phone call appointment if we both agree it is warranted.
Periodically I may send out an email to the entire class or send you an individual email. I MUST have a valid email id from you at all times to insure proper communication. If you change your email id, notify me via email.
If I send you an email and it "bounces" (gets returned as undeliverable) I will temporarily remove your access to the class web site until I establish email communication with you again.
Emails can (and do) get lost sometimes. I usually respond within 24 hours (weekends and holidays excepted) so if you do not get a reply from me within 48 hours - email again! At that point, feel free to send a copy of the email to my emergency email listed near the top of the Syllabus.
NOTE: I have a SPAM filter. It works pretty good. Sometimes too good. Sometimes it will filter out a legitimate email from you! If you suspect this is happening (or just want to prevent it from happening), then put the following somewhere in the Subject line of your email (all caps): ITSSAFE
Also, NEVER specifiy a subject line that says "Hi" or "Hello", etc. These are almost always spam. I usually delete them without reading them! A good subject line will include either the class name or the college name.
Be as specific as you can be with your questions. Please don't send an email that says, "I'm having some trouble with this assignment, can you look at the code and tell me what I'm doing wrong?" Try to get some of your program (or SQL statement) to work and then ask me about the part you are struggling with.
The best way to work on your programs is to get a little bit working at a time. Break the problem into steps and solve one step at a time. In general, don't move on to the next step until you have the previous step working.
If you are emailing me about a question/problem with something you're working on, be sure to send me your entire program (or SQL statement) as an attachment to the email. It’s very hard to help you debug your code just by your description alone.
Sometimes when I answer your questions with factual information, the tone of my reply can sound cold and unfeeling. That's not my intention! I answer a lot of email, and if I'm really busy, I may give you "just the facts". Please don't interpret that as a form of abruptness that means I want you to go away! :-D Ask as many questions as you need to :-)
By the way, I usually go by "Steve", not "Professor". The whole "Professor Perry" thing is just so I could have cool Web site name :-)
Written Communication Policy
In the past I've gotten a number of emails that are very difficult for
me to read because they are so poorly constructed.
Back in high school, I was never a particularly good English student. Now, many years later, I'm beginning to understand why it was important to learn what they were trying to teach me! :-D
This written communication policy doesn't demand perfection or formal writing. It does have some (very basic) rules you must follow or I won't read your message!
Rules:
- Write in complete paragraphs! Cover only one topic per paragraph!
It's very hard to read emails when the ideas are all run together. Don't give me a "stream of consciousness". Here's a particularly bad example (somewhat modified to protect the guilty :-D )
"Thanks for checking the status of my assignment. I probably should have got back to you sooner about finishing the class but thought you knew I was going to the class website and was trying to figure it out without bothering you. Which brings me back to my original problem. I was trying too over wright one of the program I down loaded (Assignment 2) and it did not over wright. I know this because had a test for the category on the original program and left it off the new program but it kept testing. How does one over wright on the class website? The reason for this was my check for the select code always came up false even with the correct code entered. I was trying to figure out if my program was able to reach the interface or the functions. There is no error about not finding the functions or an error at all. The printout on the web page is perfect but the results are screwy."
It would take me a long time to parse an email like this and respond to the individual points. I won't do it!
- Use proper capitalization and spelling. Do not write in "text messaging!"
Example:
hey steve how r u? im doin gr8 w/asgn 6 wut is the next 1?
I don't expect perfect spelling in your emails (Lord knows, I'd be a big hypocrite to expect that!), but your emails shouldn't be riddled with spelling errors either.
Give me a fighting chance! I'm trying to understand what you are saying ;-)
- Give me the relevant history to support what you are asking about.
I have about 200-250 students during a semester and if you refer to a previous post by you (or another student) I'm not likely to remember it. Just copy it into the email you are sending me (or leave in the Email history when replying.)
Read your emails after writing them to make sure they make sense. Be sure that you are giving me enough information so I can help you effectively.
- Try not to go on long tangents.
I answer a lot of email, so if yours is the 20th one I'm answering this hour, I tend to just look for the relevant details so I can answer your questions.
I don't want to take all the humanity out of our communications, just know that I probably don't have the time to read anything too involved about your personal life ;-)
Your emails should still be informal and conversational. It's ok to make jokes and be funny! We all need a little humor to make it through the day! :-)
- Remember to give me your full name and the class you are in.
Consequences:
If I find that your email (or communication) is in violation of these rules, I will answer them with "Please rework this email following the written communication guidelines discussed in the Syllabus".
I'm not planning to be "anal" about this! :-D I just want you to make it easier for me to help you :-)
Assignments
There are a number of assignments that will require you to solve problems using
PHP/MySQL programs or answer questions.
The Final Exam will be broken up and taken over the course of the semester. You should read the information contained by clicking on the "Final Exam Information" link BEFORE answering any of the questions.
I require that you read the material shown when you click on the "Best Programming Practices" link found on each Assignment page. A portion of your grade for each assignment will be based on how well you adhere to these practices.
Students may work with their own Web servers if they wish, but their final submitted PHP/MySQL programs MUST compile and work on the practice server I provide. I will test all program assignments on the practice server only!
For an overview list of the Learning Objects and their assignment due dates, please click on the "Learning Objects & Grading" link on the main page of the class Web site.
There is a "Grading Criteria" link in the Assignments section of the Learning object (if applicable) which describe the criteria I will use to grade your programming assignments. Read it carefully!
Assignments will generally be graded within 7 days of your submission.
The Assignments must be submitted in the order they are due and the class Web site will enforce this by not enabling the link for an Assignment until the previous Assignment has been submitted.
Each assignment has a target due date. There is a 7-day grace period for every assignment. One penalty point is deducted from your score for each day (past 7 days) that your assignment is turned in late . For example, if an assignment is 10 days late, and is worth 10 points, the highest score you could receive for it would be 7 points.
I really do want this class to be focused on your learning and not on keeping a schedule. My leniency, however, is designed for students who start the class work at the beginning of the semester and are having difficulties keeping up.
It's important to start the class right away, and try to keep reasonably close to the pace of the class.
There are some additional rules...
Remember that NO assignments or exams will be accepted after the FINAL DATE of this class (listed under Important Dates) unless I've given you an explicit extension.
You may work through the class faster than the schedule if you wish, however, you may NOT submit more than one assignment on any given day.
This rule has two purposes. One, to keep you from rushing through the material and, two, to keep students from submitting most of their assignments during the last week of class!
How To Approach the Assignments
It's popular to say, "I make my assignments real-world."
Well, yes and no.
The assignments are not real-world in that I don't require you to make them "production-ready", that is, we are not trying to develop fully working applications that are ready to use in the business world.
In the real world, you write your applications in such a way that user input is fully validated and unexpected data can be handled gracefully. In this classroom situation, we will practice some of that, but I am not trying to get you to handle every possible error condition in the assignments. In the real world you would attempt to do that.
I do have a "Best Practices" section that shows you the way your program should be coded. This concerns things like indenting and naming rules, etc. Following these criteria is part of every programming assignments grade.
Here's an important tip:
My assignments are intentionally fuzzy! I write the requirements for an assignment almost in the same way that someone would talk to you e.g. "Oh, and I need a counter for the number of rows displayed."
You can't get any more real world than that!
You will sometimes need to "gather the requirements" from the assignment description in the same manner as if you were talking to a user. The requirements are not always laid out the in the order you need to perform the tasks and every requirement may not be grouped together with like-tasks.
Sometimes, it may seem that I've left out some information you need. Or you don't understand something. Well, what would you do in the real world if that happened?
You'd ask someone a question!
I expect that you will ask me questions BEFORE you submit an assignment.
The assignment target due date schedule is very relaxed, so there is almost no reason to submit an assignment that is not working! Work with me before you turn in the assignment!
When I grade assignments I hate to find things wrong and take away points. So keep working with me until you get the assignment right before submitting it for grading.
I want you to get full credit for an assignment just as much as you do!
Debugging Your Programs
The best way to work on solving the problems is to get a little bit
working at a time. Break the problem into steps and solve one step at a
time. Then move on to the next step and get it working, and so forth.
If you are completely lost, it is usually because you are trying to get too much of the problem solved at one time.
If you've found you've gotten too far into a program and are confused, try commenting out large areas of the coding until your program does something correctly. Then start uncommenting small portions of code to try and isolate the problem.
Another technique is to display messages to yourself from within the program at intermediate points. Say that a formatted name is not appearing properly on Web page, for example. You might display the unformatted name first to see that it was retrieved properly.
While I will help you debug your programs, the ultimate responsibility is yours.
I will usually give you much more specific debugging help in the beginning of the class, but as time goes on my comments will become more general and I will expect you to go through the debugging techniques described above.
If, after the first few assignments, you find that you are not "getting it" that is a sign that this class is probably not for you and you should consider withdrawing with a "W" before the cut-off date.
In some case, you may just need some more experience before attempting the class again.
Cheating
Any student found to be cheating on an exam or programming assignment
will receive zero points for that assignment.
It's perfectly acceptable for students to work with and help one another, however, it is not acceptable for students to hand in the same exact (or very near exact) solutions.
Do NOT share code! If you want to help another student show them an example of how you solve a particular problem, don't give them the exact code or design that you will be submitting for your assignment.
Sometimes students think they can copy assignments and then "just change a few things around" to disguise the fact. Don't try it. Almost everyone who does slips up and leaves in some telltale similarity that I pick up on.
If I detect that code has been shared or copied, ALL students involved will receive zero points for that assignment, even if you have already received a grade for that assignment. For example, if Student A submits an assignment on March 1st and gets 8 points, then Student B submits the assignment a week later and I notice it is a thinly disguised rework of Student A’s assignment, I will go back and change Student A’s grade to 0 points along with Student B’s grade.
If a student is caught cheating more than once, they will be expelled from the class and receive an automatic "F" for the semester.
Grading Policy and Standards
| 70-90% | Assignments |
| 10-30% | Final Examination |
Grading Scale
The standard SJSU SLIS Grading Scale is utilized for all SLIS courses:
| 97-100 | A |
| 94-96 | A- |
| 91-93 | B+ |
| 88-90 | B |
| 85-87 | B- |
| 82-84 | C+ |
| 79-81 | C |
| 76-78 | C- |
| 73-75 | D+ |
| 70-72 | D |
| 67-69 | D- |
| Below 67 | F |
Academic Integrity
Your own commitment to learning, as evidenced by your enrollment at San José State University, and the University's Academic Integrity Policy requires you to be honest in all your academic course work. Faculty members are required to report all infractions to the Office of Student Conduct and Ethical Development. The policy on academic integrity can be found at http://sa.sjsu.edu/student_conduct.
Reasonable Accommodation of Disabilities
If you need course adaptations or accommodations because of a disability,
please e-mail me as soon as possible. Presidential Directive 97-03 requires
that students with disabilities register with the Disability Resource Center
(DRC) to establish record of their disability.
No matter where students reside, they should contact the SJSU DRC to register. The DRC Web site: http://www.drc.sjsu.edu/
One Washington Square - San José, California USA, 95192-0029
Phone: 408-924-2490
Contact the webmaster
