Other technical problems involved us learning and understanding new technologies that we hadn’t seen before. These included ASP and Dream Weaver. And also we had to become much more competent in technologies we had previously done, like JavaScript, HTML, Access, SQL, Rational Rose, UML and Paint Shop-Pro.
4. What has been learned?
During the entire project we learned how to communicate and work together as a team. There were many ideas and thoughts that had to be discussed and decisions had to be made on many functionalities and features of the project.
Team Work Skills
There were two members in our project group and we worked well together. We both learned and researched many topics that were of interest to the project and came together to talk about what we had learned e.g. which technologies to use. When it came to implementing these ideas we split the workload but worked in close proximity so as to discuss any problems that may have arisen during the implementation. It is very important when working in groups that no one person makes important decisions without the input or collaboration of the others involved. We feel we achieved this, as we both knew what the other was working on at all times. This avoided the overlapping of work in progress.
4.1 Technologies learned
Now to examine what actually was learned from a technical perspective, from the initial stages of the project it was difficult to anticipate what technologies were going to have to be learned. But once research was undertaken in the analysis stage and the design stage it became a lot clearer to us what tools and techniques were going to be needed and what new tools and techniques were inevitability going to have to be learned. We had covered the majority of the tools and techniques in previous years but there were still some aspects that we were going to be covering new ground.
Since we were using ASP we found it was better to use an Access back end to implement the database. Having done Access the year before it was easy enough to implement the database but we had never seen ASP before, which is basically an Active Server Page. We learned that ASP is a HTML page that includes one or more scripts (small embedded programs) that are processed on a Microsoft Web server before the page is sent to the user. An ASP is somewhat similar to a server-side include, in that all involve programs that run on the server, usually tailoring a page for the user. Typically, the script in the Web page at the server uses input received as the result of the user's request for the page to access data from a database and then builds or customizes the page on the fly before sending it to the requestor. This technology wasn’t that difficult to implement but did take a bit of time to get it right.
Another technical skill we learned was ODBC, which is basically Open Database Connectivity, a standard database access method developed by Microsoft Corporation. The goal of ODBC is to make it possible to access any data from any application, regardless of which database management system (DBMS) is handling the data. ODBC manages this by inserting a middle layer, called a database driver, between an application and the DBMS. The purpose of this layer is to translate the application's data queries into commands that the DBMS understands. For this to work, both the application and the DBMS must be ODBC-compliant that is, the application must be capable of issuing ODBC commands and the DBMS must be capable of responding to them. Subsequently our website application and Access database was capable with ODBC.
In saying that we have learned some totally new technologies from scratch we also learned how to use previously used technologies with greater competency, like JavaScript, HTML, Access, SQL, Rational Rose and Paint Shop-Pro. And we even learned some technologies like Oracle and Java that ended up not even being used.
Consequently the whole idea behind doing a project is to teach students how to work as a team and also learn new and interesting technologies in the meantime. We feel as a group we have achieved these objectives as we have learned an abundance of new skills and technologies, which will undoubtedly come in very useful in the future.
4.2 Time Allocation
A crucial element in working on a project is the budgeting and allocation of time. In the early stages of the project we underestimated the pressure that other course work and assignments would put on our project schedule .We also had to attend classes during this time and we found that spending every day in lectures and every night on the project was taxing. We eventually learned to allocate our time efficiently so no subject suffered. This was difficult as the project and assignment deadlines came closer and closer. We had to rewrite some of our design phase at the request of our Project Supervisor. This didn’t help our project schedule. We ideally should have started implementation earlier, however this would be true for all projects ever undertaken as there is always more than can be done and there is always more than one way to do it.
5. What would you do differently?
There are many things that we would do differently if we were to start the project over again. The following are the main points.
5.1 The Use of JSP’s
When we researched JSP’s (Java Server Pages) as a potential connection tools for our project. The following information made us wonder if it would be a better idea to use these instead of ASP’s. However, we did not have to time to try and implement it as there were a lot of different aspects of the project which we had to force our time on learning and implementing. If we had a third member in the group this would have been more possible.
What are JSP’s?
Servlets are modules that extend request/response-oriented servers, such as Java-enabled web servers. For example, a servlet might be responsible for taking data in an HTML order-entry form and applying the business logic used to update a company's order database. Servlets are to servers what applets are to browsers. Unlike applets, however, servlets have no graphical user interface. Servlets can be embedded in many different servers because the servlet API, which you use to write servlet, assumes nothing about the server's environment or protocol. Servlets have become most widely used within HTTP servers; many web servers support the servlet API.
How are JSP’s (servlets) useful?
Servlets are only instantiated when the client first accesses the program. That is, the first time any client hits the URL that is used to access the servlet, the servlet engine instantiates that object. All subsequent accesses are done to that instance. This keeps the response time of servlets lower. Also, because a servlet is instantiated only once, all accesses are put through that one object.
Because JSP’s allow collaboration between people a servlet can handle multiple requests concurrently, and can synchronize requests. This allows servlets to support systems involving on-line communications. As our system may generate an environment where multi request handling is needed, the use of these servlets may have been more efficient as a middleware tool for our project.
5.2 Configuring of our own Client/Server Architecture
As opposed to placing our project on a free web server such as Brinkster we would attempt to implement Client/Server architecture.
To implement this we would need the use of two PC's one as the client requesting services from the server where all the requested services are running. We would build our project on a Windows machine with this machine acting as the server. We would then need the use of a client computer.
To establish a connection between the client and server machines we needed both machines to have network cards that would connect both machines using two UTP device cables. This would establish a connection. Next we would have to configure the IP addresses of the client and server. Once these are configured both machines would be able to talk to each other.
5.3 Flexibility
We could install any software we liked on our own server and even run any heavy-duty programs we needed. As we would be the server administrators, we could do pretty much anything we liked.
5.4 Better Time Scheduling
We think the first thing to do would be to visualise how we could do the project, as we wasted a lot of time in the early stages trying to decide what to do our project on, producing two feasibility studies before deciding what to do. Maybe it would have been useful to us if we had of had our feasibility study completed before we came back to college. Consequently this would have given us valuable research time, as this is vital in producing an efficient system.
Also another aspect that we felt we could of done differently is implementing a tighter schedule, since we found during the year that we weren’t that strict on adhering to the weekly schedules which were draw up in Microsoft Project. This had a knock on effect to the latter stages of development leaving a lot of work to be done. And even forcing us to omit certain features, like one or two of the games and it meant that we had to use Hot Potatoe to generate two of the games. We felt that if we had of kept closer to the schedule there wouldn’t be as much of a panic in the latter stages. This would also have given us more time to implement the database through Oracle instead of staying with Access.
5.5 Website Design Aspects
There were different areas of the web design that we could of done differently namely:
- Implement keyboard support
- Test our site on actual users
Keyboard support is an aspect of the interface design that we didn’t look into at all as our project interface is almost totally mouse orientated, making it difficult to navigate using the keyboard apart from using the tab key. So this is an aspect we would do differently. We would probably implement it in a similar fashion to the way it’s done in the Microsoft applications. Like in MS Word to access the file menu you press [alt] [f]. So we would for example if you wanted to access the home page you would just press [alt] [h]. And we would have the [h] underlined to indicate to the user that [h] is the key letter. We would also document this in the user manual in case users weren’t familiar with this technique. It is still possible to navigate using the [tab] key, although this is more time-consuming.
Testing the site on actual users is something we didn’t do, we did test the site on other classmates, but this was be a bit biased as all our classmates are accomplished Internet users and well used to navigating through the net. So we feel as a group that if we were to do it differently we would test the site on all types of user’s not just classmates. This would give a much fairer refection of the usability of the site.
Usability is the measure of a product's potential to accomplish the goals of the user. Some factors used in determining product usability are ease-of-use, visual consistency, and a clear, defined process for evolution.
Usability testing is a method by which users of a product are asked to perform certain tasks in an effort to measure the product's ease-of-use, task time, and the user's perception of the experience. Usability testing can be done formally, in a usability lab with video cameras, or informally, with paper mock-ups of an application or Web site. Changes are made to the application or site based on the findings of the usability tests. Whether the test is formal or informal, usability test participants are encouraged to think aloud and voice their every opinion. Usability testing is best used in conjunction with user-centred design, a method by which a product is designed according to the needs and specifications of users.
6. Changes to the project since the design report.
There were a few things that ended up changing from our analysis and design reports to the actual implementation. Firstly we changed the age group ranges. Instead of giving them specific ages we divided them into three categories, kids, teenagers and adults. We felt this gave a wider range and scope to the groups than the exact ages and also let the user decide which suited them the best.
6.1 Interface Changes
Our interfaces changed quite a lot from our initial designs. We made our pages a lot more colourful than our original proposal. There was a puzzler heading at the top of each separate page so we had the consistency running throughout the entire website however we had separate themes of pictures on each individual group. For the kids we had a bug from “A Bugs Life” on the left hand side above and below the buttons, as shown below. This was each of the pages in the kids section until they logged out. We also arrange all our buttons on the left hand side of all the pages. This lead to a more user-friendly system.
The teenager page was designed with the same things in mind. The puzzlers heading stayed the same so the user recognises it always no matter which group they are in but down the side we used pictures of Calvin from the comic strip Calvin and Hobbes, as shown below. This same picture was shown throughout all the teenagers pages keeping it consistent again until they log out. There are a lot more pictures here on the site than previously planned brightening up the pages and entertaining the user as well.
The adults page, shown below, has a theme of smurfs running down the side by the buttons. These, as with the kids and teenagers, stay there throughout the adult portion of the site. Again the puzzlers title is there all the time as well, providing recognition of the website to everyone. Again more pictures and some animation were used to make the pages more eye catching than was previously designed.
Each of the other links from the home page i.e. admin, contact us, message board etc. had their own themes running through their own pages as well. They all had the puzzler logo on the top with their separate pictures running down the left hand side, and have the same feel as the pages shown above.
6.2 Games
Also the games that we were planning on doing changed. In our design document we provided a couple of samples of games that we were thinking of using. We did not however end up using any of these, generating our own ones instead than basing them on other peoples from different web sites. The brainteaser part that we were planning on using in the adult page changed too. We did keep these brainteasers however they were not on a separate link. Instead we just had one written on each home page with the answer down the bottom of the page just to entertain each user straight away as they enter into their own home page.
6.3 Tools and Techniques
In the design phase it was difficult to really say what technologies we were going to be using, as we were very inexperienced in a lot of the technologies, because we had never used most of them before. So as a group we did a lot of research into the different areas and gave an educated estimate of what tools and techniques we would be using. Subsequently once the implementation started we found some of the technologies weren’t as compatible with our system as we had first anticipated.
In the design report we had said we were going to be using
- Rational Rose
- UML
- Java
- XML
- HTML 4.0
- Front Page
- Dream Weaver
- Oracle
- Access
- My SQL
- Java Script
- JSP
In the implementation we didn’t uses some of these tools and techniques and we subsequently substituted new techniques, which we believed would be more compatible with the system. The final list of tools and techniques we used is namely
- Rational Rose
- UML
- ASP
- ODBC
- HTML 4.0
- Front Page & Dream Weaver
- SQL
- JavaScript
- (Brinkster Server) Microsoft Windows 2000 Server
- Microsoft Access
- Paint Shop-Pro
- Hot Potatoe
The differences starting with the added technology of ASP which stands for Active Server Page, is a HTML page that includes one or more scripts (small embedded programs) that are processed on a Microsoft Web server before the page is sent to the user. Typically, the script in the Web page at the server uses input received as the result of the user's request for the page to access data from a database and then builds or customizes the page on the fly before sending it to the requestor.
ASP is really just a substitute for XML. So we used ASP solely for programming the games room and connecting the Website to the Database. Along with Open Database Connectivity (ODBC), which is an open standard application-programming interface (API) for accessing a database.
Another new tool we used in the web design along with Front Page was Dream Weaver as it had a few features on it that Front page didn’t have like template design features.
Other changes involved implementing JavaScript mainly for validation purposes and to implement Snake and X’s and O’s; this was an aspect that was over looked in the design phase. Creating these two game took a lot longer than we had first considered. And obvious additional tools like Paint shop pro (used to create images and logos) and FTP (used to transfer files to the server) were necessary which were also overlooked in the design.
We initially thought we would be hosting our site on the emhain Apache server, but since we found that ASP wasn’t compatible with this server we had to find an alternative host server and the best option we found was on www.brinkster.com which has free web space and also supports ASP. Perfect for hosting our site.
The final change from the design report was from using Oracle to using Access; this was changed mainly due to time constraints. We felt it would be better to implement the system first through Access as we are very competent in this tool just to get the functionality of the rest of project up and running and if we had time later to transfer the Database into Oracle we would. Consequently as time was tight towards the end of the implementation stage we felt as a team that it would be sufficient to stay with Access.
7. A technical description of the implementation.
The implementation phase can be split into five different sub-areas, which are namely the database design, website design, implementing a connection between the database and the website, games (puzzles) implementation and system testing.
7.1 Database Design
The first task we decided to take on was the database design, and with this task we initially intended to us Oracle to implement the database, but as we were running into time restrictions we decided to use Access because we had used it before and we would be able to draw up the tables and the relationships between them in little or no time. The intention behind implementing the database through Access first was that we could get the rest of the project connecting to it and if we had time later on when the rest of the project was finished we would go back and implement it using Oracle. Consequently we did run out of time in the latter stages of the project, so we decided to leave the database implemented through Access.
7.2 Website Design
The next stage was to design the website; this was relatively easy as we had gained a lot of experience in this field through our previous assignment for Mary Lyng as she gave us guidelines in interface design. To do this task we used a combination of two applications namely FrontPage and Dream Weaver. Using these applications made the process of design relatively quick instead of coding raw HTML. Like for example if we wanted to insert a drop down menu it was simple as you just clicked on [insert] [form] and select [drop down menu] and the HTML code was supplied in the background, although there was occasions that we needed to revert back to the source code to implement the features we needed, but all in all it was a relatively quick and easy process.
Another area of the website design was the validation process, so that when users enter their details incorrectly or not at all, we display an error message to the user. The way that we implemented this was by using JavaScript, which we had little experience of but soon got to grips with. As FrontPage or Dream Weaver didn’t have an automate validation process we had to hard coded the JavaScript into the source code within FrontPage and Dream Weaver. This was a tedious and time consuming process but was necessary to ensure correct entries into the database.
7.3 Connectivity between Database and Website
Once we had the database and the website designed the next task was to connect the information entered in the website to be stored in the database. There were five primary procedures that need to be accomplished namely logon, search for a record, add a record, delete a record and update a record. We found this part of the project probably the most difficult as we had no experience in ASP (Active Server Page) and little experience in SQL which was needed to implement this task.
What an ASP basically consists of as explained previously is a HTML page that includes one or more scripts (small embedded programs) that are processed on a Microsoft Web server before the page is sent to the user. An ASP is somewhat similar to a server-side include or a common gateway interface (CGI) application in that all involve programs that run on the server, usually tailoring a page for the user. The script in the Web page at the server uses input received as the result of the user's request for the page to access data from the database we implemented. We used an ASP in conjunction with SQL, which is (Structured Query Language) a standard interactive and programming language for getting information from and updating a database. Queries take the form of a command language that lets you logon, search for a record, add a record, delete a record and update a record, which were the necessary procedures for us. The ASP and SQL is embedded in the HTML source and is enclosed in <% %>. The way we really got to grips with these technologies was really by trial and error, but once we got the initial procedures working like logon, search for a record, add a record, delete a record and update a record. It was easy to transfer the code to other parts of the system.
7.4 Games Implementation
From the outset we didn’t really know how we were going to implement the games. The main problem was deciding what games to use and what the best language for that game would be. We had a number of different ideas, but we ended up using Java script to implement Snake and X’s and O’s. For the other games on the website we used a games generator called Hot Potatoe. We would have liked to have had the time to code some more of our own game, but because of the demands of college and outside obligations this was not possible.
7.5 Testing the System
Testing is an area that we could of done a better more thoroughly; as it was left to the last minute, thankfully we did unit test the different parts of the system as we went alone which helped tremendously in the latter stages.
But once the system was finished we first did a functionality test, which we participated in ourselves. This brought most unseen bugs to the surface. Most of the results from this test were coding errors like not having input validated or not having database outputs formatted. This was a long and tedious process as we had to perform every type of functionality the system was capable of doing, to make sure that every page loaded up correctly, every database request was correct, validation was correct on the input pages etc. The best way we found to complete this process as quickly as possible was to assign each member specific pages to test and record the errors and once all the errors were collected we could work together to resolve the problems.
Then once we where happy with the functionality of the system we proceeded with the usability testing. With time restrictions we only got to test the system on other classmates which was probably a bit biased as our classmates are all competent computer users making it easier for them to navigate through the system. But what this test really achieves is feed back indicating if the system is organised in a logical and use-sensitive manner with clear navigation, if it is an easy to use interface without need for training or documentation, if it has good response times, like for example the users aren’t left waiting for a page to download, if it has intuitive navigation for a wide audience of users, if it has compatibility with a wide range of browser configurations, if it has consistency in terms of site identity which is done by developing a page template involving contact information, layout, logos and other information and finally if it is easy to locate and retrieve required information at the site.
The specific criteria we actually tested for was navigation ease, match between system and the real world, user control and freedom, consistency and standards, error prevention, aesthetics, understandable error messages, help documentation, response times, browser compatibility and general functionality.
The results from these tests were very satisfactory as the feedback from the testers was good as they found the system extremely easy to use and a lot of the testers were complementary on the aesthetics of the interface. The actual percentage result from all the testers in the different areas is illustrated below.
7.6 Usability Test Results
1. Very Bad
2. Bad
3. Satisfactory
4. Good
5. Very Good
(This test was conducted on 20 people)
8. Possible future enhancements.
8.1 Electronic Mail Service
Email is another feature we thought about implementing, as it is another communication medium that would be beneficial to the endeavour of the project. Obviously the higher the variety of mediums on the site the more attractive the site will be towards potential members. But reasons similar to both implementing SSL and SMS was that we just found we didn’t have enough time and also we felt our project difficult was high enough already.
Email is basically the exchange of computer-stored messages by telecommunication. E-mail messages are usually encoded in ASCII text. However, you can also send non-text files, such as graphic images and sound files, as attachments sent in binary streams. E-mail is one of the protocols included with the Transport Control Protocol/Internet Protocol (TCP/IP) suite of protocols. A popular protocol for sending e-mail is Simple Mail Transfer Protocol and a popular protocol for receiving it is POP3. Meaning to implement an email service we would have to be competent in these areas namely SMTP and POP3, which are probably the two protocols we would use, as they are the most popular.
The first protocol for email is SMTP (Simple Mail Transfer Protocol) and it is a TCP/IP protocol used in sending and receiving e-mail. However, since it's limited in its ability to queue messages at the receiving end, it's usually used with one of two other protocols, POP3 or Internet Message Access Protocol that let the user save messages in a server mailbox and download them periodically from the server. In other words, users typically use a program that uses SMTP for sending e-mail and either POP3 or IMAP for receiving messages that have been received for them at their local server. Most mail programs such as Eudora let you specify both an SMTP server and a POP server. On UNIX-based systems, sendmail is the most widely used SMTP server for e-mail. A commercial package, Sendmail, includes a POP3 server and also comes in a version for Windows NT.
The second protocol used for email is POP3. POP3 (Post Office Protocol 3) is the most recent version of a standard protocol for receiving e-mail. POP3 is a client/server protocol in which e-mail is received and held for you by your Internet server. Periodically, you (or your client e-mail receiver) check your mailbox on the server and download any mail.
An alternative protocol is Internet Message Access Protocol (IMAP). With IMAP, you view your e-mail at the server as though it was on your client computer. An e-mail message deleted locally is still on the server. E-mail can be kept on and searched at the server.
POP can be thought of as a "store-and-forward" service. IMAP can be thought of as a remote file server.
POP and IMAP deal with the receiving of e-mail and are not to be confused with the Simple Mail Transfer Protocol (SMTP), a protocol for transferring e-mail across the Internet. You send e-mail with SMTP and a mail handler receives it on your recipient's behalf. Then the mail is read using POP or IMAP.
These are the main protocols that we would have to become familiar with if we were to enhance our system with an email service.
8.2 Flash Macromedia
With all websites nowadays the look and feel of the interface (aesthetics) is absolutely vital in retaining users attention. In keeping this aspect in mind a possible future enhancement would be to implement Flash, which is a popular authoring software developed by Macromedia, it is used to create vector graphics-based animation programs with full-screen navigation interfaces, graphic illustrations, and simple interactivity in an antialiased, resizable file format that is small enough to stream across a normal modem connection, which inevitability improves the interface.
A vector graphic is the creation of digital images through a sequence of commands or mathematical statements that place lines and shapes in a given two-dimensional or three-dimensional space. In physics, a vector is a representation of both a quantity and a direction at the same time. In vector graphics, the file that results from a graphic artist's work is created and saved as a sequence of vector statements. For example, instead of containing a bit in the file for each bit of a line drawing, a vector graphic file describes a series of points to be connected. One result is a much smaller file.
At some point, a vector image is converted into a raster graphics image, which maps bits directly to a display space (and is sometimes called a bitmap). The vector image can be converted to a raster image file prior to its display so that it can be ported between systems.
A vector file is sometimes called a geometric file. Most images created with tools such as Adobe Illustrator and CorelDraw are in the form of vector image files. Vector image files are easier to modify than raster image files (which can, however, sometimes be reconverted to vector files for further refinement).
Animation images are also usually created as vector files. For example, Shockwave's Flash product lets you create 2-D and 3-D animations that are sent to a requestor as a vector file and then rasterized "on the fly" as they arrive.
The software is ubiquitous on the Web; both because of its speed (vector-based animations, which can adapt to different display sizes and resolutions, play as they download) and for the smooth way it renders graphics. Flash files, unlike animated but rasterized GIF and JPEG, are compact, efficient, and designed for optimised delivery.
Known as a do-it-yourself animation package, Flash 4 gives Web designers like us the ability to import artwork using whatever bitmap or illustration tool we prefer, and to create animation and special effects, and add sound and interactivity. The content is then saved as file with a .SWF file name extension.
We feel implementing Flash in our interface would create a more attractive and user-friendly environment for users to feel comfortable and enjoy using the system.
8.3 Instant Messaging Service
Instant messaging (sometimes called IM or IMing) is the ability to easily see whether a chosen friend or co-worker is connected to the Internet and, if they are, to exchange messages with them. Instant messaging differs from ordinary e-mail in the immediacy of the message exchange and also makes a continued exchange simpler than sending e-mail back and forth. Most exchanges are text-only. However, some services allow attachments. In order for IMing to work, both users (who must subscribe to the service) must be online at the same time, and the intended recipient must be willing to accept instant messages. (It is possible to set your software to reject messages.) An attempt to send an IM to someone who is not online, or who is not willing to accept IMs, will result in notification that the transmission cannot be completed. If the online software is set to accept IMs, it alerts the recipient with a distinctive sound, a window that indicates that an IM has arrived and allowing the recipient to accept or reject it, or a window containing the incoming message.
Under most conditions, IMing is truly "instant." Even during peak Internet usage periods, the delay is rarely more than a second or two. It is possible for two people to have a real-time online "conversation" by IMing each other back and forth.
8.4 Tracking of Games
We would develop an added feature on the games room that would be able to track the number of times a user completed a game. The system would then be able the tell that user that it has completed eg X’s and O’s so many time, would they like to play again or move onto the next game.
We had hoped that this would be up and running for the demo but unfortunately we ran out of time. It was the next item on our list to implement.
9. Project Schedule
10. Conclusion
This concludes our final year project. Through out the development of the project the team has learned an abundance of new skills ranging from vital experience in working as a team like delegating and compromising skills to learning new and interesting technologies. Although our initial goal of creating a website with all our own games wasn’t achieved we did subsequently achieve developing a website with a jazzy, user friendly interface which we feel is more than satisfactory. Our reasoning behind not achieving our initial proposal was mainly down to inexperience as we were extremely naïve about how long it would take us to develop such a system. As we didn’t take into account other responsibilities we had with other subjects throughout the year. But we did learn in a sense the hard way that scheduling really is a fundamental part of software development and crucial to have your estimates as accurate as possible from the outset.
But in saying that, we are happy at the way that this project has turned out. Obviously given more time we would have done a lot more, and possibly have made it a commercial product. The project is an aspect of the course we as a team enjoyed the most and felt it was a great way of using a wide range of modern technologies, which will hopefully stand to us in our future careers in the industry.
11. Acknowledgements
We like the take this opportunity to thank Mary Power, our project supervisor, for her continuous help throughout the year. And members of our class for participating in our system test and for relaying back vital information on the system.
And we would also like to thank everyone at ASP Forums () and ASP Forums Zone (http://asp.forumszone.com) for their willingness to help us our with code problems.
12. References
Website Researched
http://www.1keydata.com/sql/sql.html
http://archive.ncsa.uiuc.edu/General/Training/PerlIntro/
http://www.microsoft.com
http://www.webmonkey.com
http://www.hotwired.lycos.com
http://www.google.com
http://www.yahoo.com
http://www.whatis.com
http://www.macromedia.com
http://www.webspace.com/server
http://developer.intel.com/design/servers/buildingblocks
http://developer.intel.com/design/servers/buildingblocks
http://www.2cpu.com/How-To/serverbuilding.htm
http://www.asp.net/
http://www.asp101.com/
http://java.sun.com/products/jsp/
www.apl.jhu.edu/~hall/java/Servlet-Tutorial/
www.microsoft.com/office/access/default.asp
www.acc-technology.com/