Everyone in this course will be building an online learning community, a site where users teach each other. The work may be done alone or in groups of two or three students. Ideally, you or your instructors will find a real client for you, someone who wants to publish and administer the community on an ongoing basis. A good client would be a non-profit organization that wants to educate people about the subject surrounding its mission. A good client would be a medium-sized company that wants a knowledge-sharing system for employees. A good client would be a student group at your university. If you can't find a client, pick something that you're passionate about. It could be Islamic architecture. It could be African Cichlids (a family of freshwater fishes, living mostly in the rift lakes of East Africa; see www.cichlid.org). It could be cryptography. Pick something where you think that you can easily get or generate magnet content, some tutorial information that will attract users to your service.
You are building the same type of project as everyone else in the class. Thus it will be easy for you to compare approaches to, for example, user registration or content management.
Before you starting writing code, however, we'd like you to do some planning and competitive analysis. Fundamentally you need to answer the questions "Who is going to teach what to whom?" and "What alternatives are currently available for this kind of learning?"
First, consider the overall objective of photo.net: A place where a person can go and get the answer to any question about photography.
Second, consider levels of administrative privilege. There are site-wide administrators, who are free to edit or delete any content on the site. These administrators also have the power to adjust the authority of other users. We have moderators who have authority to approve or delete postings in particular discussion forums. Finally there are regular users who can read, post, and edit their own contributions. A less popular service could probably get away with only two levels of admin privilege.
A different way of dividing the users is by purpose in visiting the service:
A final way of dividing users that may be useful is by how they connect. In the case of photo.net, it is easy to envision the Web browser user. This user is uploading and downloading photos, participating in discussions, reading tutorials, shopping for equipment, etc. The same person may connect via a mobile phone, in which case he or she becomes a mobile user. If the mobile user is in the middle of a photographic project, we want to provide information about nearby camera shops, processing labs, repair shops, time of sunset, good locations, and other useful data. If the mobile user is connecting for social purposes, we need to think about what are practical ways for a person on a mobile phone to participate in an online community. Our engineering challenge is similar for the telephone user.
/doc/ directory.
To assist you in this task we've created a couple of examples for an online learning community in the area of general aviation:
Don't spend more than one hour on this exercise; plenty of truly awful software has been written with fancy user profiles on the programmers' desks. There is no substitute for launching a service to real users and then watching their behavior attentively.
Whenever Nick Gittes (1902–2000; grandfather of one of the authors)
would see a computer advertised on television, he'd say "A home
computer. Why would anyone want a thing like that?"
The dotcom boom is over. You ought to have a good reason for building an information system. If a curmudgeon wants to know why you need all these fancy computers instead of a book, some chalk, and pencil and paper, it would be nice to have a convincing answer.
There are good reasons to look at the best elements of offline resources and systems. After several millenia, many of these systems are exquisitely refined and extremely effective. Your online community and technology-aided learning environment can be much improved by careful study of the best offline alternatives.
The magazine is ineffective for start-to-finish learning. It is impossible for Popular Photography to sell enough ads to run a twenty-page tutorial article much less a complete beginner's textbook on photography. The magazine is ineffective for finding the average price for a used or obscure item. (Shutterbug is the place for used and classic camera dealer ads.)
The magazine is ineffective as a means of getting answers to arbitrary questions. There is a "Too Hot to Handle" section in every issue that promises "Honest, forthright answers to your most probing questions." Unfortunately, only four questions are answered per issue. Presumably these were submitted at least a couple of months previously. And the answers come only from the editors of the magazine; they don't tap the reserves of knowledge that may reside among the hundreds of thousands of subscribers.
The magazine is ineffective as a means of exhibiting reader work. The "Your Best Shot" column displays five or six reader-contributed photos in every issue, but being selected is a slow and uncertain process.
Face-to-face courses require more travel, time, effort, and commitment than many people are able to give. Once the course is over, the student is unable to avail him or herself of mentoring and critiques from the instructor and other students.
The second force that prevents concentration in the world of online learning communities is the nature of community itself. Christopher Alexander, Sara Ishikawa, and Murray Silverstein argue in A Pattern Language (Oxford University Press 1977) against countries of more than a few million people:
"It is not hard to see why the government of a region becomes less and less manageable with size. In a population of N persons, there are of the order of N^2 person-to-person links needed to keep channels of communication open. Naturally, when N goes beyond a certain limit, the channels of communication needed for democracy and justice and information are simply too clogged, and too complex; bureaucracy overwhelms human process. ...If it were possible for everyone to pile into a single community and have a great learning experience, America Online would long ago have subsumed all the smaller communities on the Internet. One of the later chapters of this book is devoted to the topic of growing an online community gracefully to a large size. But, for now, rest assured that it is a hard problem that nobody has solved. Given sufficiently high quality magnet content and an initial group of people dedicated to teaching, there will always be room for a new learning community."We believe the limits are reached when the population of a region reaches some 2 to 10 million. Beyond this size, people become remote from the large-scale processes of government. Our estimate may seem extraordinary in the light of modern history: the nation-states have grown mightily and their governments hold power over tens of millions, sometimes hundreds of millions, of people. But these huge powers cannot claim to have a natural size. They cannot claim to have struck the balance between the needs of towns and communities, and the needs of the world community as a whole. Indeed, their tendency has been to override local needs and repress local culture, and at the same time aggrandize themselves to the point where they are out of reach, their power barely conceivable to the average citizen."
robots.txt file that will instruct search engines to
exclude certain content. You may get a friendlier response from
copyright holders if you agree to provide a hyperlinked credit and to
ensure that their content does not become multiply indexed.
If you have a client who is supplying all the magnet content, write down a summary of what is going to be available and when. Next to each class of documents note the person responsible for assembling and delivering them. As an engineer, it isn't your job to assemble and develop content, but it is your job to identify risks to a project, such as "not enough magnet content" or "nobody has thought about magnet content".
www.google.com, into machine-readable and
network-routable IP addresses, e.g., 216.239.57.100. DNS
is a distributed application in that there is no single computer that
holds translations for all possible hostnames. A domain registrar,
e.g., register.com, records
that the domain servers for the google.com domain are at particular IP
addresses. A user's local name server will query the name
servers for google.com to find the translation for the hostname
www.google.com. Note that there is nothing magic about
"www"; it is merely a conventional name for a computer that runs a Web
server. The procedure for translating a hostname such as froogle.google.com
is the same as that applied for translating www..
something.mit.edu. You and your client will need to
navigate the IT bureaucracy to register that hostname and map it to
the IP address of your server. If you're building a service for a
client who does not have an Internet domain, encourage them to
come up with a good name and register it. The authors have had good
experience with register.com, a
service that includes bundled use of their DNS servers; the domain
owner can edit the hostname-to-IP-address translations with a Web
browser interface.
During this course, for example, you will ideally want to retain ownership of all software that you produce. You will therefore be free to reuse the code in any way, shape, or form. The client, however, is going to be putting in a lot of time and effort working with you over a period of months and is thus entitled to some benefit. Your university tuition payments have probably drained away all of the cash in your bank account and therefore you won't be giving the client money as compensation for his or her time. What you can do is give the client a license to use your software. This obviously benefits the client but it also benefits you. The more people that are out there happily running your software the better your professional resume looks.
Should you try to limit what the client can do with your software? Generally this isn't worthwhile. Any organization that comes to you for programming assistance is probably not an organization that will want to hang out a shingle and offer to develop software for others. If they do decide that it would make sense to adapt your software to another application within the company, it is very likely that they will call you first to offer a consulting fee in exchange for your assistance.
How about limiting your liability? Oftentimes software engineers are called upon to write programs whose failure would have catastrophic results. Suppose that you are offered $100,000 to write a trading program for an investment bank. That may seem like a great deal until the bank sues you for $100 million, alleging that a bug in your program cost them $100 million in lost profits. In the biomedical field a bug can be much more serious. There is the famous case of the Therac-25 radiation treatment machine, bugs in whose control software cost lives (see http://sunnyday.mit.edu/therac-25.html).
Disclaiming liability is difficult, even for trained lawyers, and
hence this is best left to professionals. Nearly every commercial
software license includes a disclaimer of warranty. Here's a snippet
from the Microsoft End User License Agreement (EULA):
19. DISCLAIMER OF WARRANTIES. TO THE MAXIMUM EXTENT PERMITTED BY
APPLICABLE LAW, MICROSOFT AND ITS SUPPLIERS PROVIDE THE SOFTWARE AND
SUPPORT SERVICES (IF ANY) AS IS AND WITH ALL FAULTS, AND HEREBY
DISCLAIM ALL OTHER WARRANTIES AND CONDITIONS, WHETHER EXPRESS,
IMPLIED, OR STATUTORY, INCLUDING, BUT NOT LIMITED TO, ANY (IF ANY)
IMPLIED WARRANTIES, DUTIES OR CONDITIONS OF MERCHANTABILITY, OF
FITNESS FOR A PARTICULAR PURPOSE, OF RELIABILITY OR AVAILABILITY, OF
ACCURACY OR COMPLETENESS OF RESPONSES, OF RESULTS, OF WORKMANLIKE
EFFORT, OF LACK OF VIRUSES, AND OF LACK OF NEGLIGENCE, ALL WITH REGARD
TO THE SOFTWARE, AND THE PROVISION OF OR FAILURE TO PROVIDE SUPPORT OR
OTHER SERVICES, INFORMATION, SOFTWARE, AND RELATED CONTENT THROUGH THE
SOFTWARE OR OTHERWISE ARISING OUT OF THE USE OF THE SOFTWARE. ALSO,
THERE IS NO WARRANTY OR CONDITION OF TITLE, QUIET ENJOYMENT, QUIET
POSSESSION, CORRESPONDENCE TO DESCRIPTION, OR NON-INFRINGEMENT WITH
REGARD TO THE SOFTWARE.
This is so important to Microsoft that it is the only part of a
twelve-page agreement that is printed in boldface and the only part that
is presented in a French translation for Canadian customers as well.
20. EXCLUSION OF INCIDENTAL, CONSEQUENTIAL, AND CERTAIN OTHER
DAMAGES. TO THE MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW, IN NO
EVENT SHALL MICROSOFT OR ITS SUPPLIERS BE LIABLE FOR ANY SPECIAL,
INCIDENTAL, PUNITIVE, INDIRECT, OR CONSEQUENTIAL DAMAGES WHATSOEVER
(INCLUDING, BUT NOT LIMITED TO, DAMAGES FOR LOSS OF PROFITS OR
CONFIDENTIAL OR OTHER INFORMATION, FOR BUSINESS INTERRUPTION, FOR
PERSONAL INJURY, FOR LOSS OF PRIVACY, FOR FAILURE TO MEET ANY DUTY
INCLUDING OF GOOD FAITH OR OF REASONABLE CARE, FOR NEGLIGENCE, AND FOR
ANY OTHER PECUNIARY OR OTHER LOSS WHATSOEVER) ARISING OUT OF OR IN ANY
WAY RELATED TO THE USE OF OR INABILITY TO USE THE SOFTWARE, THE
PROVISION OF OR FAILURE TO PROVIDE SUPPORT OR OTHER SERVICES,
INFORMATION, SOFTWARE, AND RELATED CONTENT THROUGH THE SOFTWARE OR
OTHERWISE ARISING OUT OF THE USE OF THE SOFTWARE, OR OTHERWISE UNDER
OR IN CONNECTION WITH ANY PROVISION OF THIS EULA, EVEN IN THE EVENT OF
THE FAULT, TORT (INCLUDING NEGLIGENCE), MISREPRESENTATION, STRICT
LIABILITY, BREACH OF CONTRACT, OR BREACH OF WARRANTY OF MICROSOFT OR
ANY SUPPLIER, AND EVEN IF MICROSOFT OR ANY SUPPLIER HAS BEEN ADVISED
OF THE POSSIBILITY OF SUCH DAMAGES.
21. LIMITATION OF LIABILITY AND REMEDIES. NOTWITHSTANDING ANY DAMAGES
THAT YOU MIGHT INCUR FOR ANY REASON WHATSOEVER (INCLUDING, WITHOUT
LIMITATION, ALL DAMAGES REFERENCED HEREIN AND ALL DIRECT OR GENERAL
DAMAGES IN CONTRACT OR ANYTHING ELSE), THE ENTIRE LIABILITY OF
MICROSOFT AND ANY OF ITS SUPPLIERS UNDER ANY PROVISION OF THIS EULA
AND YOUR EXCLUSIVE REMEDY HEREUNDER (EXCEPT FOR ANY REMEDY OF REPAIR
OR REPLACEMENT ELECTED BY MICROSOFT WITH RESPECT TO ANY BREACH OF THE
LIMITED WARRANTY) SHALL BE LIMITED TO THE GREATER OF THE ACTUAL
DAMAGES YOU INCUR IN REASONABLE RELIANCE ON THE SOFTWARE UP TO THE
AMOUNT ACTUALLY PAID BY YOU FOR THE SOFTWARE OR U.S.$5.00. THE
FOREGOING LIMITATIONS, EXCLUSIONS, AND DISCLAIMERS SHALL APPLY TO THE
MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW, EVEN IF ANY REMEDY FAILS
ITS ESSENTIAL PURPOSE.
If you don't want to cut and paste Microsoft's verbiage, which might expose you to a copyright infringement action from Redmond, consider employing a standard free software or open-source license, of which the GNU General Public License is the best-known example. Note that using a free software license doesn't mean that your software is now free to the world. You may have licensed one client under the GNU GPL but whether or not you decide to offer anyone else a license is a decision for the future.
If you wish, you can use the sample contract at the end of this book as a starting point in negotiating rights with your client. And remember that old bromide of business: You don't get what you deserve; you get what you negotiate.