useful programming resources
W3 Schools programming resources
Learning Ruby, an interactive Guide
An HTML validation tool, Very Important
Lists and CSS styles elegantly explained
Step by step lessons in PHP programming
Useful tools
Text Wrangler - General Purpose text editor
Transmit Text Edit and FTP client
The Total Validator validation tool
This is the hardest part of the whole process to get into one's head. Once you have this part, everything else should slide into place. The process is complicated, full of jargon the more important parts seem anal retentive. Here goes.
Our little project is a library, and libraries are full of books. Even a small library will have several thousand volumes. The librarians don't just toss them on the shelves and trust that the visitor will find the book he wants. And if the visitor wants a particular book, there should be a list that shows what books are there. So, how do you organize that list? How do you organize the books on the shelves?
When your client comes into the library looking for a particular author or a particular book, he should be able to walk to a particular location and find it. Most libraries sort the shelves by topic. It is the source of the Dewey Decimal System. If you want to read about the battle of Vicksburg, you can go to the shelf where the librarians keep those books together, 973.734.
If you can remember the days Before Computers were Ubiquitous, you might remember the old card catalogs. These were small file drawers full of 3 X 5 cards. There were two sets of drawers. An author set and a title set. Here in Multnomah County there was not the iron consistancy there was at Portland State regarding book sorts. The fiction titles were in the stacks aranged by author name, with mysteries and Science Fiction having their own set of stacks. Biographies were sorted by subjects last name.
Lets start our list. It should have
there are more things that can go on our list, such as cover type, number of pages, publisher, but this will do for our purpose, as it has enough complications to make this web page useful, but not enugh to make it run 2000 pages.
As you remember, we have a list of books for our library here. I have three different views of the list, which you saw on the first page. Here they are again.
If most folks are like me, they have a definite goal in mind when they head to the book shelf. They want a particular kind of book. Most libraries organize their books by kind, then by author. if you like science fiction, you look up all the science fiction books like so:
+---------------------------+---------------+--------+ | title | author | topic | +---------------------------+---------------+--------+ | 1632 | Eric Flint | Sci-Fi | | 1635, The Baltic War | Eric Flint | Sci-Fi | | Bellweather | Connie Willis | Sci-Fi | | To Say Nothing of the Dog | Connie Willis | Sci-Fi | +---------------------------+---------------+--------+
And if you have a particular writer you like, you can go to your list and find him like so...
+----------------+-----------------+--------------+ | title | author | topic | +----------------+-----------------+--------------+ | Humans | Donald Westlake | Fantasy | | Why me? | Donald Westlake | Mystery | | High Adventure | Donald Westlake | Romance | | Kahawa | Donald Westlake | Spy Thriller | +----------------+-----------------+--------------+
Right away, you can see old Don is going to have you wandering all through the stacks looking for his stuff.
if you were to write out a table organized by author, with each column a different book, with a column next to it telling what kind, right away you would run into problems. Most writers are pretty prolific. Westlake has been writing for years and he sometimes does two books a year. And he has a huge variety of output. Right away you can see that your list is going to be a mess.
Normalization is a way of organizing data so that it is consistent and there is no redundant data and all dependencies make sense. Instead of having one monster table, you have a series of related tables where each entity has its own table and its own Id. This leads to a lot less repetition in the data, and it makes the data easier to maintain. If your writer writes another book, all you have to do is add the book and the relationship. You don't have to re write the whole list of books written by the writer. Also errors are easier to catch and fix if there is one instance of that piece of data, rather than many different instances. Also we get the benifit of consistency. He is identified the same way for each volume. He is not Donald Westlake here, D. Westlake there, Donald E Westlake over there, and if we make a typing error, we can fix the problem of Donald Wesltake, or prevent it occuring in the first plalce.
One of the teaching and programming tools out there is the Entity Relationship diagram. It is easy to start out by thinking of entities as physical objects. As we move along, we will see that really isn't the case, but it makes a good start. We have a book, we have writer. The writer can be bald, astigmatic, elderly, and crotchety. He has a separate existence from his books. Which can be dusty, thick and have hard covers. One writer can write several books. And a book can have several authors. One author can write several kinds of books. The best way of dealing with these entities is to give each of them a separate table. Each member of the table should have its own key. For entities that have many to many relationships, the relationship itself should have its own table where the keys match the relations. Examples on the next page.