text:
Statics/Newton's Laws and Equilibrium

They are not the law pertaining to Statics The laws are some bit different then this, They Are the sources of Statics

Newton's First Law
Newton's first law states that an object that remains in uniform motion will remain in uniform motion unless it is acted upon by an external force. This also includes that an object at rest will remain at rest unless it is acted upon by an external force. When more than one force acts upon an object, the vector sum of these forces is the resultant force.

When the resultant force on an object is zero, it will remain at rest if it is at rest, or continue to move in a straight line at a constant velocity if it is in motion. There is no change in either the magnitude or direction of its velocity. That is, there is zero acceleration. This concept can also be applied to motion in any selected direction.

Consider an object moving along the x-axis. If no net force is applied to the object along the x-axis, it will continue to move along the x-axis at a constant velocity with no acceleration.We can extend this to the y- and z- axes.

In any system, unless the applied forces cancel each other out, that is, the resultant force is zero, there will be acceleration in the direction of the resultant force.The net force on such an object is zero

Force Equilibrium
In static systems, where motion does not occur, the sum of the forces in all directions must always equal zero (otherwise, it's a dynamics problem). This concept can be represented mathematically with the following equations.

Rotational Equilibrium
The concept also applies to rotational motion.

If the resultant moment about an axis is zero, the object will have no rotational acceleration about the axis. If the object is not spinning, it will not start to spin. If the object is spinning, it will continue to spin at the same constant angular velocity. Again, we can extend this to moments about the y-axis and the z-axis. This is represented mathematically with the following. ..............................................................................................................................................

What happens if the sum of forces or moments is not zero?
If the object has a net moment not equal to zero, it will spin about whichever axes are not zero. If the object is acted upon by a net force not equal to zero, it will accelerate in whatever direction the net force is. Once the object moves it cannot be analyzed with statics; instead, the rules of dynamics take over. The acceleration of the object is governed by Newton's second law,

$$\sum F = m \cdot a $$

You will never need this equation in Statics.

title: Statics/Newton's Laws and Equilibrium


text:
User:67.123.165.163

dgffjdogkmj;lfsknfss/elkosr;imufl;srioe;sd/gkdl/tud/lmkbd/ln

license: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/

title: User:67.123.165.163


text:
Talk:Statics

Really liked the clean layout of the Calculus book so used a similar format for the Statics book. Think I captured most of the topics for a one-semester course in Statics. --CRPierce 02:08, 23 December 2005 (UTC)

impact force on truss
can anyone point me to info, formulas or procedures for calculating impact stress on truss members having different cross sections. Sean

Recategorised, note on naming and TOC
Hi,

I recategorised the pages of this book from the (very large) |Category:Engineering to |Category:Statics, which is now a subcategory of Engineering.

Just a note: since you're using colon naming, it's a good idea to make sure you put the TOC template on all pages (I didn't notice you had it on some pages until 1/2 way through). Colons are supposed to be disallowed by the current naming ploicy, but I plan to bring that to debate: see Wikibooks talk:Naming policy for details. -- SB_Johnny | talk 11:11, 18 August 2006 (UTC)

Expanding Book
Hi, I was interested in working on expanding and formating this wikibook considerably in the near future. I was wondering if there were any objections, thoughts, or comments on the matter. Star*texan (talk) 17:36, 10 October 2009 (UTC)

title: Talk:Statics


text: Adventist Youth Honors Answer Book/Nature


text:
MediaWiki Administrator's Handbook

This book is a guide for administrators of MediaWiki--the software that runs Wikipedia.

Contents

 * 1) /Preface/
 * 2) Explanation of Admin-specific Tools
 * 3) Deletion and Undeletion - how and when to use these tools.
 * 4) /Page Protection/
 * 5) /User Block/
 * 6) /Sidebar/
 * 7) /Importing/ - how and when to use this tool.
 * 8) /Block/ - how and when to use this tool.
 * 9) /Edit History/ - how and when to merge or split up edit histories.
 * 10) /Protect/ - how and when to use this tool.
 * 11) /Rollback/ - how and when to use this tool.
 * 12) /Special pages/ - special pages only available to administrators.
 * 13) /Editing in the MediaWiki Namespace/ - changing the appearance of the project.
 * 14) Aspects of Being a Responsible Administrator
 * 15) /Introduction/
 * 16) /Being a Project Leader/
 * 17) /Recent Changes Patrol/
 * 18) /Spam and Spammers/ - dealing with spam and spammers.
 * 19) /How to Handle Copyright Violations/
 * 20) /Countervandalism IRC Bots/
 * 21) Wikimedia-specific
 * 22) /Asking for help/ - where to go on individual projects to request advice.
 * 23) /Wikimedia projects/
 * 24) /Pages to watch/ - what pages administrators may wish to watch on individual projects.
 * 25) /Combating spam/ - advice for those doing anti-spam work

Related books

 * MediaWiki Developer's Handbook
 * MediaWiki User Guide

MediaWiki MediaWiki pour débutants MediaWiki Manuale del software Wiki nl:Portaal:MediaWiki Handbok för Wikimedias Administratörer

title: MediaWiki Administrator's Handbook


text:
Talk:MediaWiki Administrator's Handbook

Why this? Why here?
There may be something on Meta like this as well. Who cares? I'm doing this mainly for new admins on Wikibooks, but I would like to make this generic for all Wikimedia admins as well. Feel free to jump in and help out with this. --Rob Horning 06:21, 23 December 2005 (UTC)

 * Where is it... m:Help:Contents... m:Help:System admin... no, that is for users who edit php files... m:Help:Editor... m:Help:Reverting... "Admin-only "rollback" link"... I guess that there is no separate section of Meta for admins/sysops.

 * The current MediaWiki Handbook is a mess. Officially, this book is one-to-one with the "Help:" namespace at Meta, and each page can be copied to each Wikimedia project, but when I was copying Help:Introduction earlier today, I had several problems with broken and obsolete links on m:Help:Introduction which I tried to fix. Not only is there an entire set of deprecated pages under Documentation, but several pages (linked from m:Help:Hacker for example) are not in the "Help:" namespace. Further there were some red links that I changed to point to English Wikipedia; I also found stubs of encyclopedia articles at Meta. As for the content, some modules are outdated; the other modules document every obscure feature of MediaWiki 1.6devel without explaining them well.

 * A book that explains how to be an admin/sysop, and without all those confusing templates at Meta, is a good idea. I will not contribute much, but if the book becomes more generic (to include UseModWiki for example), then I might contribute, or maybe I will contribute to Wiki Science. Meanwhile, I might also try to fix the MediaWiki Handbook. Actually, I am not sure what I plan to do. --Kernigh 04:22, 25 December 2005 (UTC)

Meta Source Material
This is another area where perhaps having a separate Wikibook on the subject is going to help clear up a mess on Meta as well. The key sources for assisting Admins (sysop status) on MediaWiki projects is not m:Help:System admin but rather m:Help:Moderator, as what on Wikimedia projects we call Admins are really moderators from the double speak that takes place on the meta pages. What the MediaWiki handbook calls administrators is really developers, or people who have direct access to the computers that are running MediaWiki software. Admins on Wikibooks and other Wikimedia projects don't have that level of access (unless they are working to become a developer). There are some gems in some other pages of the MediaWiki handbook that may be useful for admins, but it takes time to sort through all of the extra material to find it, as the MediaWiki handbook in those sections is geared more toward the developers and people running their own MediaWiki server. --Rob Horning 07:40, 30 December 2005 (UTC)

Rename to MediaWiki Administrator's Handbook?
I think the book should be renamed. Many non-Foundation sites use MediaWiki now and a good portion of the info (deleting, banning, etc. etc.) would be just as applicable to them as to us. Of course there could still be Foundation-exclusive pages like explaining Vfd and whatnot. GarrettTalk 21:51, 3 January 2006 (UTC)

 * I'm not tied to this particular name myself. There are some unique aspects of the Wikimedia culture that do need explaining to the non-initiated, but most of that can be translated to other projects as well.  It is also something that other projects could learn from as well, especially when dealing with larger projects.  Attempting to be a moderating force in a collaborative writing environment is an interesting community role to play, and where the true strength of being an admin really comes into play.  --Rob Horning 14:58, 4 January 2006 (UTC)

Moving this book to the Help namespace
This was a stealth move when a bunch of other stuff was happening. I don't think this belongs in the help namespace, although that can be up to debate. I originally wrote this as a book that would be a conventional Wikibook, even though the emphasis is indeed to be of assistance to sysops of MediaWiki projects.

Given no major objection for a couple of weeks, I'm going to revert the book name back to the main namespace and out of the help namespace. This is a conventional Wikibook, and I hope that people contribute to it as such. It was never my intention to make this a Wikibooks-specific manual. --Rob Horning 19:47, 19 July 2006 (UTC)

How to differentiate each target audience for each MediaWiki reference manual: Developer, Sysop, Admin, Editor, User
Peter Blaise says: I think there is poor identification and differentiation of who uses and who works in, on, around, and under a wiki. Rather than just duplicating existing resources, I suggest we brainstorm and come up with something new. I suggest a functional analysis - how each user / worker functions, what they do, and how they do it. Here are a few overlapping levels of users / workers as I experience Mediawiki installations, in order here from top (customer / end user) down to the penultimate service provider, the original coder. I find that I'm dividing my time and paying attention to three areas in my Mediawiki installations:

 * Content - User, Editor, Admin.
 * Here I see Users, Editors and Admins dealing with Articles, Discussion / Talk pages, and Categories.
 * Read and print content.
 * Contribute content.
 * Edit and manage content.
 * Manage Users, Editors, Admins.
 * Browser-level access to site controls.

 * Function - Admin, Sysop.
 * Here I see Admins and Sysops dealing with all the on-screen controls and what those controls do, and the underlying programs.
 * All of the above.
 * Access under the web browser.
 * Install, configure, update.
 * Operating System level tasks.

 * Structure - Sysop, Developer.
 * Here I see Admins, Sysops and Developers going behind the scenes, underneath the user interface, installing, configuring, updating, using the Operating System and other tools, and creating, finding, and installing enhancements.
 * Creates and modifies core software and extensions.
 * programmer
 * needs overview and details of programming.
 * installs, configures,
 * needs software choices and code information,
 * has access to "layers" below HTML, such as operating system and code edits.

I have no problem with one manual for all three - there just needs to be three levels of depth. Writing three or more separate manuals seems silly to me since each subsequent level of depth needs the previous level of information. I'll create a simple example:

I can't imagine a Developer wanting a reference manual showing "navigation" menu programming controls without also at least explaining what the "navigation" menu is and how it functions, as well as how to modify it with built-in controls, without the need for programming unless they want to go beyond that. Also, as an "Function and Structure" Admin, I appreciate more than just changing the "navigation" menu with available tools, but also customizing it or adding programming-like items to it, as well as understanding where I may need to go if I want more, including a tease or invitation to "do it yourself" and dabble in Development.

In other words, I see no benefit to separate manuals, and I see all the benefits to having one, complete, all-inclusive Mediawiki reference manual. The challenge may be to easily make the depth of displayed information tunable so I can toggle or nicely enter / exit successive depths if I'm curious, and come back without getting lost.

Otherwise, I might as well just go to Google each time I need to look something up and let Google dynamically assemble my Mediawiki manual each day for me whenever I'm ready for more.

Does this make sense to anyone else? How could we accomplish this? Is there, or can we make, MediaWiki extensions that help structure a reference manual on a wiki - table of contents, page navigation controls back and forth with bookmarks to return to the same page and post it notes to highlight our discoveries, and an encyclopedic index to help us look up definitions, not just search-results listing every time the word is used? I look at Special:Version and I see no "book" publishing extensions here yet. Why is that? peterblaise 15:33, 21 September 2007 (UTC)

--

References in print:
 * "MediaWiki Administrators’ Tutorial Guide"
 * Mizanur Rahman, Packt Publishing 2007
 * http://www.packtpub.com/Mediawiki/

 * "Wikis for Dummies"
 * Dan Woods, Peter Thoeny, Wiley Publishing 2007
 * http://www.wiley.com/WileyCDA/WileyTitle/productCd-0470043997.html

 * "Managing Virtual Teams: Getting the Most from Wikis, Blogs, and Other Collaborative Tools"
 * M. Katherine Brown, Brenda Huettner, Char James-Tanny, Wordware Publishing 2007
 * http://www.wordware.com/Merchant2/merchant.mv?Screen=PROD&Product_Code=1598220284

Not yet released (as of 2007-09-21):
 * "Professional Wikis"
 * Mark S. Choate, Wiley Publishing 2007
 * http://www.wiley.com/WileyCDA/WileyTitle/productCd-0470126906.html

 * "WikiPatterns"
 * Stewart Mader, Wiley Publishing 2007
 * http://www.wiley.com/WileyCDA/WileyTitle/productCd-0470223626.html

 * more: http://books.google.com/books?q=wiki&btnG=Search+Books

Web references: ... and so on.
 * http://www.mwusers.com/forums/forumdisplay.php?f=4
 * http://meta.wikimedia.org/wiki/Help:Administration
 * http://www.mediawiki.org/wiki/MediaWiki
 * http://mywiki.ncsa.uiuc.edu/wiki/MediaWiki_Servers
 * http://www.mediawiki.org/wiki/Manual:System_administration

 * This is exactly how we should be dividing these books up. The other consideration is whether the book is written to be specific to Wikibooks, MediaWiki wikis in general, Wikipedia, Wikimedia projects in general etc. I've left some comments on various talk pages in this set of texts about some small-scale re-organization, but more is needed. I have some notes written down - I'll perhaps put them up somewhere to better coordinate things. — Mike.lifeguard | talk 01:48, 29 January 2009 (UTC)

Deleting a User
Hello... Can anybody tell me please, how i can DELETE an allready registered User?

Thanx for your help 89.166.146.220 (talk) 10:56, 10 March 2008 (UTC)

You can't. The technical reason behind this is that then revisions attributed to that user would break. You can use an extension to re-attribute changes to a new user, though.
 * You actually can, but it's a very bad idea. mw:Extension:RenameUser is a safer alternative. You can try mw:Extension:DeleteAndMerge if you're adventurous. — Mike.lifeguard | talk 01:46, 29 January 2009 (UTC)

Header "3"
Hello! Do you know why there is a  instead of  ? Is this a typo? --Valerio Bozzolan (discuss • contribs) 08:23, 23 February 2020 (UTC)
 * As an alternative to the typo theory, it may have been someon's stylistic preference. --Pi zero (discuss • contribs) 12:40, 23 February 2020 (UTC)

title: Talk:MediaWiki Administrator's Handbook


text:
Talk:Circuit Theory/Energy Storage Elements/RL and RC Circuits

could we please explain more in detail the formulas used in this text, they seem to need further explaination via a drawing


text:
Talk:Network Plus Certification

Original comment
This book seems pretty dead, which is unfortunate. I fixed some spelling errors anonymously, before realizing the lack of content. I have now created an account and intend on add some content myself; I've done some N+ studying and saved my notes. I don't actually have the certification yet, because I haven't finished everything, so I can't promise a completed text for a while. ;) -WMD (2:20am EST, 12/22)

Second comment
I would have to vote against combining this page with the Network Plus Certification book. That book has significantly more detail than is necessary for a cram. Bjadter (talk) 22:59, 21 May 2008 (UTC)

Additional Resources
I added titles to each of the comments, in order to cause a nice Table Of Contents on this discussion page. I don't understand Bjadter's comment (the second comment). This page is considered to be part of the Network Plus certification Wikibook. What combining would be needed? And who is saying that cramming is desired? Anyway, if anyone wants another resource, I've made one at [CyberPillar ] [ guide to CompTIA Network+ N10-005]. and I would be happy to discuss plans to improve that guide or this one. I presume that the comment, which I labelled as "Original comment", predates the second comment which appears to be from the year 2008. Also, There are other resources that I think could be helpful, like [CyberPillar ] [\s VLSM chart]. 174.21.246.238 (discuss) 08:16, 30 December 2014 (UTC)

title: Talk:Network Plus Certification


text:
User:WMD

Hi. I'm just a 17-year old who found out about this place on Slashdot. I'm a computer nerd and I don't get out much. Despite this, I hope to contribute some worthwhile content where I can.

title: User:WMD


text:
User:Lineweaver

Graduate Student, UC-Berkeley Department of Chemistry

Francis Research Group

title: User:Lineweaver


text:
Talk:Organic Chemistry/Chirality/Enantiomers

I would posit that some enantiomers are not configurational isomers because they can be interconverted via bond rotation. BINAP and BINOL ligands, for example, can be converted from the R to the S enantiomer by rotation about the biphenyl bond. Remember that enantiomers are defined by a mirror-image relationship, and not a stereocenter-dependent relationship!--Lineweaver 08:05, 23 December 2005 (UTC)


text:
User:Iluvblender

Hi.

My name is Satish Goda and I Love Blender. I am from India and have been Blendering for 10 years.

Links:
 * 1) My Website
 * 2) My YouTube Channel

title: User:Iluvblender


text:
C Sharp Programming/Classes

As in other object-oriented programming languages, the functionality of a C# program is implemented in one or more classes. The methods and properties of a class contain the code that defines how the class behaves.

C# classes support information hiding by encapsulating functionality in properties and methods and by enabling several types of polymorphism, including subtyping polymorphism via inheritance and parametric polymorphism via generics.

Several types of C# classes can be defined, including instance classes (standard classes that can be instantiated), static classes, and structures. Classes are defined using the keyword followed by an identifier to name the class. Instances of the class can then be created with the keyword followed by the name of the class.

The code below defines a class called with properties  and  and with empty methods  and. It also defines a class that instantiates and uses the  class:

Methods
C# methods are class members containing code. They may have a return value and a list of parameters, as well as a generic type declaration. Like fields, methods can be static (associated with and accessed through the class) or instance (associated with and accessed through an object instance of the class methods as well as a generic type declaration.

From C# 4.0 onwards, it is possible for a method to have optional parameters with default values, as users of C++ already know. For example, the method

can be called with one parameter only, as the second parameter, dx, is initialised to a default value.

Constructors of classes
A class's constructors control its initialization. A constructor's code executes to initialize an instance of the class when a program requests a new object of the class's type. Constructors often set properties of their classes, but they are not restricted to doing so.

Like other methods, a constructor can have parameters. To create an object using a constructor with parameters, the command accepts parameters. The code below defines and then instantiates multiple objects of the class, once using the constructor without parameters and once using the version with a parameter:

Output: Start Constructed without parameters Parameter for construction End

Constructors can call each other:

Finalizers (Destructors)
The opposite of constructors, finalizers define the final behavior of an object and execute when the object is no longer in use. Although they are often used in C++ to free resources reserved by an object, they are less frequently used in C# due to the .NET Framework Garbage Collector. An object's finalizer, which takes no parameters, is called sometime after an object is no longer referenced, but the complexities of garbage collection make the specific timing of finalizers uncertain.

Output: Constructed! Finalized!

Properties
C# properties are class members that expose functionality of methods using the syntax of fields. They simplify the syntax of calling traditional get and set methods (a.k.a. accessor methods). Like methods, they can be static or instance.

Properties are defined in the following way:

An even shorter way for getter/setter methods are accessors that do both in one line:

The code is equivalent to a GetLanguage and SetLanguage method definition, but without having to define these methods. The user can directly access the member, if it is not private, of course.

The C# keyword contains the value assigned to the property. After a property is defined it can be used like a variable. If you were to write some additional code in the get and set portions of the property it would work like a method and allow you to manipulate the data before it is read or written to the variable.

Using properties in this way provides a clean, easy to use mechanism for protecting data.

Indexers
C# indexers are class members that define the behavior of the array access operation (e.g. to access the first element of  even when  is not an array).

To create an indexer, use the this keyword as in the following example:

This code will create a string indexer that returns a string value. For example, if the class was, you could write code similar to the following:

Events
C# events are class members that expose notifications to clients of the class. Events are only fired and never assigned.

See also here for details.

Operator overloading
C# definitions are class members that define or redefine the behavior of basic C# operators (called implicitly or explicitly) on instances of the class:

Structures
Structures, or structs, are defined with the keyword followed by an identifier to name the structure. They are similar to classes, but have subtle differences. Structs are used as lightweight versions of classes that can help reduce memory management efforts when working with small data structures. In most situations, however, using a standard class is a better choice.

The principal difference between structs and classes is that instances of structs are values whereas instances of classes are references. Thus when you pass a struct to a function by value you get a copy of the object so changes to it are not reflected in the original because there are now two distinct objects but if you pass an instance of a class by reference then there is only one instance.

The structure below declares a  and a  field. Access to the field is granted through the  property :

Since C# 2.0, is possible to have arrays inside structures, but only in unsafe contexts:

The array is accessed using pointer arithmetic. Values are treat arrayed values as if they were C-style arrays using indexing, etc.

Structure constructors
Structures need constructors - or better to say initialisers, as they do not construct but just initialise the memory - so that their contents are not left uninitialised. Therefore, constructors without parametres are not allowed.

Structure variables can be assigned one to another if and only if the structure variable on the right side of the assignment are all initialised.

Static classes
Static classes are commonly used to implement a Singleton Pattern. All of the methods, properties, and fields of a class are also  (like the  method of the  class) and can thus be used without instantiating the  class:

title: C Sharp Programming/Classes


text:
Japanese/Discussion/Archives:December, 2005

Discussion
The mailing list is the first place issues should be discussed. This place is for recording decisions, and for showing which issues still need to be resolved. If you want to discuss an issue, we would urge you to join the mailing list.

If you don't want to become involved with the wikibook to the degree that you should join the mailinglist, then you may use this page to discuss issues, but we would prefer you don't.

When you do use this page to discuss issues, we ask that you please add your comments to the relevant section under unresolved issues. If there is no such section, please add one. Do not comment on more than one issue at a time. Keep your comments on topic.

Everyone who contributes regularly to this wikibook should add their name to the Japanese/Contents under the Contributors section, as well as join the mailing list.

Always add the following code at the end of your comments: &mdash; ~~~~ (four tilde marks; on most keyboards the tilde is on the key to the left of the '1' key). This shows who is posting which message to maintain continuity of the discussion. Non-registered contributors can also use that code.

Thanks. GoodStuff 08:14, 8 Nov 2004 (UTC)

Archives
Every now and again we archive old discussions to keep this Discussion page clean. Here are those archives.

 * September 2005

Mailing list
We have a Yahoo mailinglist at http://groups.yahoo.com/group/japanese-wiki/

To join the mailing list, you have two choices:
 * mail an empty message to japanese-wiki-subscribe@yahoogroups.com
 * surf to http://groups.yahoo.com/group/japanese-wiki and join with your Yahoo id. (Preferred method)

To post messages to the mailinglist, mail your message to: japanese-wiki@yahoogroups.com

The webpage will allow you to search the archives to see previous messages and view current ones. All discussion and debating should be conducted on the mailinglist, not on this page.

Thanks GoodStuff 10:03, 4 Nov 2004 (UTC)

Also, please join the irc channel #Japanese on irc.freenode.net.

To Do List
This is our to do list. These are tasks that we need doing.

 * 1) Think of and write suitable mnemonics for the kana.
 * 2) Mkn is supplying the images, and I just put in the outlines for the kana lessons. GoodStuff
 * 3) Put in examples for those kana.

 * 1) Format the JLPT 4 vocabulary lists and add English definitions.
 * 2) Here's another JLPT 4 wordlist for download: http://www.thbz.org/kanjimots/jlpt-voc-4-extra.euc
 * 3) Grouping the JLPT 4 vocabulary lists into related vocabulary lists. (Body parts, time words, house words, colors, etc tc.)
 * 4) Create new vocabulary lists, don't destroy or re-arrange the JLPT 4 lists.
 * 5) Design lesson plans

Goals of book
The primary purpose of the book is to develop proficiency in the Japanese language, specifically:

 * speaking
 * listening
 * reading
 * writing
 * cultural accustomization

This book is written for the student who either lives in Japan, or plans to do so at some point in the not too distant future. Nevertheless, the lessons and study methods are specifically designed to be effective for someone studying outside Japan, and a number of resources will be provided which will allow the student to maximize Japanese exposure at a minimal cost.

The goals for each section are broken down into both long-term goals (a level of proficiency approximating fluency) for each category as well as narrower, specific goals for each level. Currently only the basic goals have any sort of discussion backing.

Speaking
The ultimate goal of the course is to have the student conversing fluently in Japanese on any subject they are interested in. Each lesson will introduce a number of functions and tasks and provide sample dialogue, as well as vocabulary, grammar, sentence patterns, and cultural information pertaining to each. Finally, links, suggestions, and resources will be provided to allow students to practice speaking to natives in the real world.

 * basic: the goal of the basic course is to have the student able to appropriately perform basic conversational functions in Japanese (such as making requests or expressing refusal), as well as to accomplish tasks common to foreigners residing in Japan (such as making friends or going shopping).

Listening
Because speaking and listening are related functions, the functions and tasks above will also include practice which will aid the student in listening to Japanese. Additionally, resource links will be provided which will allow the student to practice their listening skills in the real world.

 * basic: the student's listening skill will be adequate to perform the tasks and functions listed in the speaking goals. The student will be able to understand the gist of simple but natural Japanese.

Reading
Japanese is a particularly challenging language because of its extensive and often ambiguous use of kanji (Chinese characters). The lessons will contain snippets of authentic sources (literature, news articles, etc.) for reading purposes, which will allow the student to not only practice identifying kanji in a natural context, but also allow for practice and discussion of grammar, usage, and discourse patterns common in the written language. To support this goal, written grammar will be explained and kanji will be taught progressively, with practice questions provided to allow students to sharpen their skills. Resources and complete external sources (literature, etc.) at the appropriate level will be provided to allow students to practice reading authentic written Japanese.

 * basic: the student will be able to read at a second-grade level, although the student's vocabulary will still be insufficient to read many authentic Japanese sources unaided. The student will be able to read kana and the first- and second-grade kanji (approximately 80-100 characters). Kana will be taught initially and then kanji will be introduced progressively.

 * intermediate: the student will develop an appreciation for discourse and stylistic conventions (e.g., newspaper Japanese).

Writing
Writing is arguably the most challenging aspect of Japanese as conversational slip-ups are often overlooked, but written language is more heavily scrutinized. Students will be provided with practice and resources which will allow them to write notes, e-mails, and short letters.

 * basic: the student will be able to write kana and the first- and second-grade kanji (80-100 characters). Focus will be put on short writing forms (notes, short expositions, etc.).

 * intermediate: the student's writing capabilities will be expanded to include essays, research papers, and creative writing.

Culture
At each level of the course, the student will have an understanding of Japanese culture sufficient to appropriately use the language learned. Cultural information will be included as part of the lesson, not as a sidebar, inasmuch as it is relevant to the way language is used. This is particularly important when learning polite and honorific speech. Other cultural information may also be introduced, and the use of authentic sources is encouraged when possible.

 * basic: the student will be introduced to the different in politeness levels as it relates to conjugations of verbs and adjectives. Additionally, they will understand the cultural meaning behind common Japanese rituals such as exchanging meishi, avoiding direct "no" responses in polite conversation, and other situations that are likely to come up in day-to-day life.

Underlying Fundamentals
To support the above goals, we will supplement the lessons with explanations of vocabulary, grammar, and kanji. These will be taught in a progressive and comprehensive fashion. Although this book is not intended to be a dictionary, grammar reference, or character book, it can and should be used along with such books to provide practice and usage examples of those concepts in a progressive fashion. All vocabulary, grammar principles, and kanji used in lessons will be explained; later lessons will build on what has been learned in previous lessons.

 * basic the sudent should have a solid understanding of basic grammar, a moderate vocabularly base, and the ability to understand and communicate with approximately a hundred kanji. The student's understanding of the fundamentals will be sufficient to pass Level 4 of the Japanese Language Proficiency Test.

 * advanced: the student should be able to function smoothly in Japan's academic, business, and other environments, pass certification tests such as the Japanese Language Proficiency Test, and have a solid linguistic foundation in the structure of the Japanese language.

Textbook Standards
Wikibooks suggests that we adopt an external set of standards to which our book should conform. This will add credibility and usability of the textbook. The following link is an example of such a set of standards.
 * State of California Foreign Language Teaching Standards
 * In terms of this set of standards, I would suggest the competencies described in Stages I and II be the goal of the Beginner course, Stage III for Intermediate, Stage IV for Advanced, and Stage V for Expert.

Aaronsama 16:51, 28 September 2005 (UTC)

--- To see previous discussion of this topic, contributed by individuals who, as of this writing had not posted here for over 8 months, please see the page history prior to 9/19/2005. --Aaronsama 13:46, 19 September 2005 (UTC)

 * I merged the previous Goals of the Basic Course section with the above. There was a lot of content overlap previously that I've tried to alleviate. I don't think the new organization is any more difficult to read or understand. --Telamon 02:30, 23 September 2005 (UTC)

Lessons arrangement

 * We have four sections. Lessons, Vocabulary, Phrases and Grammar. Each of these sections appear on the main page instead of the appendix. Lessons are not numbered so that anyone can add a lesson of whatever difficulty. The lessons link to the Vocab and Grammar pages that the specific lesson uses, so that the person can read the grammar and vocab, THEN do the lesson to see how it comes together.

 * I think we can put the JLPT stuff in an apendix page. I want vocab and gramar on the main page so that it's easily referenced. We keep this book as shallowly linked as possible. With that I mean, no vocab page in the apendix. The vocab page is a section on the front page. GoodStuff 12:37, 10 Nov 2004 (UTC)

how about organization of a specific lesson? I was typing up one, and thought up this style -
 * 1) overview/summary - introduction
 * 2) structures - key phrases/points to be discussed
 * 3) examples - bunch of examples of sentences using the structures with English equivalents
 * 4) explanation - English dissection of the structures
 * 5) practice - problems the reader can try out (no English here)
 * 6) answers - answers to the problems -- whited out such that the reader must highlight them to view (w/ English)

not sure if examples should be before explanations or not. that's sort of how children learn, but maybe it's not the best method adults .. examples after explanations? of course the explanation section would have its own short set of examples as well as it's explaining various points

thoughts?

-- Antimobius 13:22, 17 Nov 2004 (UTC)

I think we should all read up a bit on language study techniques. But "Examples before explanation" works really well. You should think in terms of "dialogue" not just "examples". Also, where do you put the vocabulary, or do you just link to appendix for vocab and grammar? GoodStuff 10:29, 18 Nov 2004 (UTC)

 * definitely. maybe looking at some ESL pages wouldn't be a bad idea, either .. as for the vocab, I hadn't actually thought about that.  I think it'd be good to have the vocab immediately available on the page, then refer the reader to the any relevant appendices
 * -- Antimobius 15:45, 18 Nov 2004 (UTC)

I guess the vocab depends on how much we want to force them to learn. I guess we can put the dialogue vocab on the page, with links to similar vocab collections. For example, we use the word "today", put that on the page, and link to "time and day words".

Okay, I looked around for some language study links, and I've added the good ones to the mailinglist bookmarks. You can find them here: Mailinglist Language Study Bookmarks I hope you find them interesting. I've only had time to skim them, but I'll read them when I get time. GoodStuff 07:44, 19 Nov 2004 (UTC)

I'm the guy who put the Exercises in. I hope you don't mind. Firstakir 19:30, 22 May 2005 (UTC)

Pitch Accent

 * As for pitch accent, I personally think that it would be nice if we put in pitch accents for all of our new vocabulary. That would certainly give us an edge over most textbooks out there. :) -- Ran 16:32, 2 Nov 2004 (UTC)

 * How will you apply the pitch marks? o-tōsan (although my dictionary uses o-tóusàn). — Mkn 18:46, 2 Nov 2004 (UTC)

 * o-tōsan looks good to me. Similarly we can have:

 * watashi
 * kazoku
 * kokoro
 * otoko

 * -- Ran 21:07, 2 Nov 2004 (UTC)

another way pitch could be approximated that I've seen is something like this -
 * 話す・は「な」す

meaning, the pitch is raised on the な and immediately lowers. however, a word's pitch can affect subsequent particles/words as well. I guess that could be shown by 「」 marks after or before the word, but that may be getting a bit overly complicated. if we show pitch at all, the one of the above methods may be a good enough approximation. it may not be 100% accurate in all cases, but it's better than not having any pitch information at all, for sure

 * this guy has a pretty long list of vocabulary words marked using this system that's compatible with JWPce

(as a side note, 私 has pitch -- the た is higher) -- Antimobius 10:24, 11 Nov 2004 (UTC)

 * That's why it's indicated that way, with no markings... basically watashi is unmarked because there is no "last high pitch" syllable.

 * If you marked high pitches instead, then you'd have:

 * watashi
 * kazoku
 * kokoro
 * otoko

 * But we won't be able to tell the difference between watashi and otoko. -- Ran 06:50, 12 Nov 2004 (UTC)

 * Nonono, you guys got it all WRONG. When indicating pitch accent, one indicated the high to low TONE FALL. Depending on which syllable the tone fall is, the pitch can easily be figured out. The difference between a word that drops it's tone after the last syllable, or one that doesn't is clear.

 * Example (drop indicated with \ and tone indicated by boldness):
 * wa\-ta-shi wa   fall on first syllable
 * wa-ta-shi\ wa   fall on last syllable
 * wa-ta-shi wa    No drop

 * For the first few times we can indicate tone with color if needs be, but what we should really do from the beginning is to indicate the tone fall in some manner. If you don't understand my explanation, then read this link, from section 1.2.4 http://www.sf.airnet.ne.jp/~ts/japanese/phoneme.html GoodStuff 09:54, 12 Nov 2004 (UTC)

 * Isn't that what I just said?! I said that there is no last high pitch on "watashi". Which means that there is no tone drop on "watashi". Which is why it's not indicated. What else could I possibly have meant?! -- Ran 16:10, 12 Nov 2004 (UTC)

 * so if we show pitch drop and pitch rise (say, in different colors/whatever), it would be kosher, eh? how would someone know that the pitch drops on the わ in わたし and rises on た if it just appears to be mono-pitched?  and how do we denote words whose pitch bleeds to the next word from the last mora, vs. words that drop pitch on the last mora?
 * -- Antimobius 11:52, 13 Nov 2004 (UTC)

 * Using the numbering scheme, it indicates where the last high pitch (or, if you like, the pitch drop) is. The scheme is already explained in the pronunciation page. It would mean a bit of memorization for the learner, but nothing too difficult.

 * The "wa" in "watashi" isn't a fall in pitch, by the way. There's a rise in pitch between "wa" and "ta". And by indicating "watashi" with a zero, or with no bolded mora, we show that there is never any fall in pitch, which means that the word predictably bleeds its pitch onto the particle that follows. On the other hand, "otoko", which can either be indicated with a bold on "ko" or a numeral "3", shows that there is a pitch drop after "ko", which means any particle that comes after is low. The rise from "o" to "to" is not indicated because it can be predicted, same goes for the rise from "wa" to "ta" in "watashi". -- Ran 14:46, 13 Nov 2004 (UTC)

Okay, what you are saying makes sense. I agree we should indicate the last high tone, rather than show what the tone of each syllable is. Bolding the last high tone could work, but I'm not sure how it would look in hiragana. I think a down slash like I used could also work. It would emphasize that the tone drop happens AFTER a mora not ON a mora.

Okay bolding does not work well on some hiragana. Here are examples:

 * おとこ
 * かぞく
 * こころ

I suggest this:

 * おとこ\
 * か\ぞく
 * ここ\ろ

It's not too pretty, but it will work. GoodStuff 11:09, 14 Nov 2004 (UTC)

Kana stroke order
Thanks to Mkn for the hard work that you put in here. :D I think though that you need a few extra steps... for example, for hiragana "su", I'm almost certain that someone is look at the diagram, and then decide to draw the downstroke through and add the circle after (GARRGH!), and for hiragana "e", I think people are going to be really puzzled about how to do the second stroke.

Also, how about more crosslinking with CJK? CJK is going to cover all the groundworks of actually writing nice (how to make the dot, how to make the horizontal stroke, how to make a square, how to make a "hito/jin" shape, etc...).

-- Ran 03:54, 19 Nov 2004 (UTC)

I dunno, the only way to accomplish what I think you want is to make animated gif images. I would be happy with small arrows just showing where each stroke starts, or an arrow head on the end of a stroke. It's up to Mkn I guess. I've got no graphics programs or skills. GoodStuff 06:40, 19 Nov 2004 (UTC)

Believe me I have thought about using arrows, but it's difficult to make it look professional when using MS Paint so I didn't include it. I welcome anyone who's good with GIMP, Photoshop, etc to add the arrows.

I used a trial software of AdGif before and it's great but the only problem is the trial version adds a watermark. See the attached example:

If anyone knows of a freeware gif animator, please let me know.

Alternatively, we can just add a description of how to write the strokes. With this description, we can mention common mistakes to avoid. An example is ホ is not written like 木 -- [[User:Mkn|Mkn (Talk)]] 15:26, 19 Nov 2004 (UTC)

 * not sure about freeware, but I have access to ImageReady, Adobe's gif animator. let me know if that helps.  I am fairly certain it doesn't insert a watermark =)
 * -- Antimobius 17:23, 19 Nov 2004 (UTC)

 * Oh Antimobius, lol, I was about to delete my comment. I feel really baka these days writing comments. It doesn't do anything. Like the saying goes: "actions speak louder than words". I found http://www.gifworks.com. It's free online gif compiler. I think I already deleted the PNG files I used to make that animation above, ZANNEN NA!! -- [[User:Mkn|Mkn (Talk)]] 17:58, 19 Nov 2004 (UTC)

 * Use the GIMP-GAP. It always worked for me. --Akir

Soundfiles on Kana
Tomos has been so kind as to offer to record soundfiles for us. I asked him to record clips for the kana so far, but he is eager to do aditional recording as well. Put on your thinking caps for good ways to apply this valuable new resource we have. Check the mailinglist for the details of his offer. GoodStuff 06:56, 22 Nov 2004 (UTC)

Conventions
A big problem with writing a Japanese textbook (as opposed to a Spanish one) is that there are so many ways to explain and talk about Japanese that as of yet there is not one widely accepted standard for issues like romanization, verb conjugation, nomenclature, etc. Indeed, each new up-an-coming Japanese linguist tries to do it in a different way. If we go with the native Japanese way of explaining things, it may get unnecessarily complex and counter-intuitive to the foreign learner, but if we do anything else we'll have to pick and choose what we deem to be the msot effective / consistent / correct way to teach.

Conventions already decided:
 * romanization

Some conventions still to be decided:
 * nomenclature for parts of speech
 * how to teach particles, particularly wa, ga
 * how to teach pronouns (do we even call them pronouns?)
 * how to teach inflection of doushi, keiyoushi, and keiyoudoushi

 * My textbook files あなた under "pronouns" and この/あそこ under "demonstrative words". I'm not even sure if the latter is a part of speech, but there it is all the same. --Telamon 05:52, 21 September 2005 (UTC)

 * What I mean with pronouns is that it can be argued (very well) that Japanese has no pronouns in the sense that Western languages do. In fact, Japanese daimeishi are indistinguishable from nouns from a purely syntactic point of view. But since Japanese do recognize daimeishi and apply that name to our pronouns when studying English, the blanket statement "there are no pronouns in Japanese" is contestible. I guess what I'm getting at is, we don't want students translating "I lent my book to my friend" as watashi wa watashi no hon wo watashi no tomodachi ni kashite ageta, so in that sense, it is useful to state that there are no "true pronouns" in Japanese, that pronouns in English usually translate as nothing in Japanese, and that Japanese daimeishi should be used only as a last resort in situations where clarification is impossible from context. As to "demonstrative words," I think they follow roughly the same set of rules, e.g. translate them into nothing unless that destroys the sentence. For example, kore wa pen desu does not sound natural unless you are trying to emphasize the pen, e.g. "No, no, no, this is a 'pen', not a mechanical pencil." Aaronsama 17:41, 28 September 2005 (UTC)


text:
.NET Development Foundation/System Types

System types and collections

System types and collections
Exam objective: Developing applications that use system types and collections.

Topics
Discussion about the concepts behind the exam objectives.

Classes, interfaces and tools
Detailed examples on how to use the classes and tools mentioned in the detailed exam objectives.

Previous / Next


text:
.NET Development Foundation/Generic types

System types and collections: Generic types

Introduction
In order to understand Generics, we should first look why we would want to use them. This is best explained with a simple example. Let's say we want to create a collection of clients, this is something that we do often. We take a simple Client class that has a name and an account number. Often an ArrayList will be used to store multiple clients in memory like this:

///   /// Representation of a client ///   public class Client {      private string _name; private string _accountNumber; ///       /// Gets or sets the account number. ///       /// The account number. public string AccountNumber {          get { return _accountNumber; } set { _accountNumber = value; } }      ///        /// Gets or sets the name. ///       /// The name. public string Name {          get { return _name; } set { _name = value; } }      ///        /// Initializes a new instance of the  class. ///       /// The name. /// The account number. public Client(string name, string accountNumber) {          _name = name; _accountNumber = accountNumber; }      ///        /// The Main entry point of the console application ///       /// The command line arguments static void Main(string[] args) {          ArrayList clients = new ArrayList; clients.Add(new Client("Marco", "332-3355")); clients.Add(new Client("Martinus", "453-5662")); foreach (Client client in clients) {              Console.WriteLine("The account {0} belongs to {1}", client.AccountNumber, client.Name); }          Console.ReadLine; }  }

This probably looks familiar for most of the readers, but by using an ArrayList we are not type safe, which is in my opinion is bad. Also we need to cast (and uncast) the object when we want to do something cool with it. With value types there is an other issue, we constantly Box and unbox the objects in the list.

A better way store the clients would be to use typed collections, this will solve the problem with type safety and we don’t have to cast the retrieved object every time we use it. A good way to do this is by inheriting an object form the CollectionBase class and looks like this: ///   /// Representation of a client ///   public class Client {      private string _name; private string _accountNumber; ///       /// Gets or sets the account number. ///       /// The account number. public string AccountNumber {          get { return _accountNumber; } set { _accountNumber = value; } }      ///        /// Gets or sets the name. ///       /// The name. public string Name {          get { return _name; } set { _name = value; } }      ///        /// Initializes a new instance of the  class. ///       /// The name. /// The account number. public Client(string name, string accountNumber) {          _name = name; _accountNumber = accountNumber; }      ///        /// The Main entry point of the console application ///       /// The command line arguments static void Main(string[] args) {          ClientList clients = new ClientList; clients.Add(new Client("Marco", "332-3355")); clients.Add(new Client("Martinus", "453-5662")); foreach (Client client in clients) {              Console.WriteLine("The account {0} belongs to {1}", client.AccountNumber, client.Name); }          Console.ReadLine; }  }   ///    /// A list of clients ///   public class ClientList : CollectionBase {      ///        /// Adds the specified client to the list. ///       /// The client. ///        public int Add(Client client) {          return List.Add(client); }      ///        /// Gets or sets the  at the specified index. ///       ///         public Client this[int index] {          get {              return (Client)List[index]; }          set {              List[index] = value; }      }   }

This looks a lot better than when we where using the ArrayList in the first example and is in general a good way to go. But what if your application grows, and we get more types that we want to store in collections like an Account, or a bank. With the 1.1 framework we had to create a new collection class for every type of object that we used, or fall back to the ugly ArrayList method. However with the new 2.0 framework MS has added Generics. This makes it possible to create classes and methods that use type parameters. This allows developers to create classes and methods that defer the specifications of certain types until the class is defined and instantiated in the code. By using the generic type parameters developers can write classes that others can use without incurring the risks involved with un-typed classes like ArrayList and reduces the work developers have to do compared to creating typed collections. So lets look at how the code looks when we are using the Generic List class from the framework.

///   /// Representation of a client ///   public class Client {      private string _name; private string _accountNumber; ///       /// Gets or sets the account number. ///       /// The account number. public string AccountNumber {          get { return _accountNumber; } set { _accountNumber = value; } }      ///        /// Gets or sets the name. ///       /// The name. public string Name {          get { return _name; } set { _name = value; } }      ///        /// Initializes a new instance of the  class. ///       /// The name. /// The account number. public Client(string name, string accountNumber) {          _name = name; _accountNumber = accountNumber; }      ///        /// The Main entry point of the console application ///       /// The command line arguments static void Main(string[] args) {          List clients = new List; clients.Add(new Client("Marco", "332-3355")); clients.Add(new Client("Martinus", "453-5662")); foreach (Client client in clients) {              Console.WriteLine("The account {0} belongs to {1}", client.AccountNumber, client.Name); }          Console.ReadLine; }  }

Thanks to Generics we have created a type-safe collection as easy as we would normally instantiate an ArrayList without writing our own typed collection. Now that we have had a brief look at how we can use Generics to reduce the amount of code we need to write, while still using typed collections let's see how we could create our custom Generic Class. To demonstrate this I have created an example Class which inherits from the DictionaryBase class. This implementation of the dictionary class will accept a GUID as the key and has a Type parameter as the value type. If you are a bit like me you will use GUIDS to identify your records in a database so using this as the key in a Typed collection was something I liked to do a lot. So now I’ve got a cool dictionary that I can use with all my objects I created when retrieving data from my database, and I will give you the code:

///   /// Representation of a client ///   public class Client {      private string _name; private string _accountNumber; ///       /// Gets or sets the account number. ///       /// The account number. public string AccountNumber {          get { return _accountNumber; } set { _accountNumber = value; } }      ///        /// Gets or sets the name. ///       /// The name. public string Name {          get { return _name; } set { _name = value; } }      ///        /// Initializes a new instance of the  class. ///       /// The name. /// The account number. public Client(string name, string accountNumber) {          _name = name; _accountNumber = accountNumber; }      ///        /// The Main entry point of the console application ///       /// The command line arguments static void Main(string[] args) {          GuidDictionary clients = new GuidDictionary; Guid clientID1 = Guid.NewGuid; Guid clientID2 = Guid.NewGuid; clients.Add(clientID1, new Client("Marco", "332-3355")); clients.Add(clientID2, new Client("Martinus", "453-5662")); Console.WriteLine("The account {0} belongs to {1}", clients[clientID1].AccountNumber, clients[clientID1].Name); Console.WriteLine("The account {0} belongs to {1}", clients[clientID2].AccountNumber, clients[clientID2].Name); Console.ReadLine; }  }   public class GuidDictionary : DictionaryBase {      public void Add(Guid id, T item) {          Dictionary.Add(id, item); }      public T this[Guid id] {          get {              return (T)Dictionary[id]; }          set {              Dictionary[id] = value; }      }   } Well it's probably not as wonderful as you expected, a lot of methods the standard dictionary has aren’t even implemented, but hey I have to leave some fun things to do for you the reader.

So what exactly did we do in the above code? We have created a Dictionary that is indexed by a Guid and uses a type parameter to limit our add method and our indexer. Now when we create a new instance of the class and specify the type parameter we have a type-safe dictionary which can be used to store and retrieve the type of objects by the given Guid.

The T in the declaration is only a name for the thing, we could as easily use the following: VeryLongNameForTheTypeParameter instead of T. Ok so we have seen how to use the type parameter to create a generic class. But before we move on to the next part lets look at the System.Collections.Generic.Dictionary<>. This class must be instantiated by providing 2 type parameters named TKey and TValue. This shows us that we can use more than one type parameter in our definition, and also shows that it was a waste of time to build my own dictionary class I could as easily used the generic dictionary like this: Dictionary and be over with it.


text:
.NET Development Foundation

Microsoft .NET Framework 2.0 Application Development Foundation

This wikibook is a collaborative study guide for the 70-536 certification exam by Microsoft

'''This wikibook is usable as is (see module objectives) and is also changing very fast. You may want to revisit periodically.'''

Choose your navigation!

 * You can go directly to a chapter:

 * Choose from the table of content on the right
 * Read thru to read the preface and a resume of each chapter
 * Or go to our All in one page where you will get the whole content on a single HTML page with a consolidated TOC (a pretty big page actually :-))

Content

 * /Introduction/
 * System types and collections
 * Exam objective: Developing applications that use system types and collections.

 * Services, threading and application domains
 * Exam objective: Implementing service processes, threading, and application domains in a .NET Framework application

 * Configuration, diagnostic, management, and installation
 * Exam objective: Embedding configuration, diagnostic, management, and installation features into a .NET Framework application

 * Serialization and input / output
 * Exam objective: Implementing serialization and input/output functionality in a .NET Framework application

 * /Security/
 * Exam objective: Improving the security of the .NET Framework applications by using the .NET Framework 2.0 security features

 * Interoperability, Reflection, and Mailing
 * Exam objective: Implementing interoperability, reflection, and mailing functionality in a .NET Framework application

 * Globalization, Drawing, and Text manipulation
 * Exam objective: Implementing globalization, drawing, and text manipulation functionality in a .NET Framework application

 * /Annexes/
 * The annexes are a series of articles on specific subjects that are referenced by the main text but were not integrated in it.

title: .NET Development Foundation


text: User:CaladSigilon~enwikibooks

title: User:CaladSigilon~enwikibooks


text: Template:InterWiki

title: Template:InterWiki


text:
User talk:CaladSigilon~enwikibooks

Official welcome
Hello and welcome to Wikibooks!

Here are some tips to help you get started:
 * You can sign your name on Talk and vote pages using four tildes, like this: ~~~~.
 * Remember to conduct any editing experiments in the sandbox.
 * Check out our help page if you need additional help.
 * Eventually, you might want to read the Manual of Style and Policies and Guidelines.
 * Templates can save your time
 * Remember to maintain a Neutral point of view.
 * Explore, be bold in editing pages, and have fun!

You will find more resources in Community Portal. If you want to ask a question, visit the Study help desk, the Staff lounge, or ask me personally on my talk page.

Good luck! -- LV (Dark Mark) 15:45, 23 December 2005 (UTC)

Your account will be renamed
Hello,

The developer team at Wikimedia is making some changes to how accounts work, as part of our on-going efforts to provide new and better tools for our users like cross-wiki notifications. These changes will mean you have the same account name everywhere. This will let us give you new features that will help you edit and discuss better, and allow more flexible user permissions for tools. One of the side-effects of this is that user accounts will now have to be unique across all 900 Wikimedia wikis. See the announcement for more information.

Unfortunately, your account clashes with another account also called CaladSigilon. To make sure that both of you can use all Wikimedia projects in future, we have reserved the name CaladSigilon~enwikibooks that only you will have. If you like it, you don't have to do anything. If you do not like it, you can pick out a different name.

Your account will still work as before, and you will be credited for all your edits made so far, but you will have to use the new account name when you log in.

Sorry for the inconvenience.

Yours, Keegan Peterzell Community Liaison, Wikimedia Foundation 23:00, 17 March 2015 (UTC)

Renamed
 This account has been renamed as part of single-user login finalisation. If you own this account you can |log in using your previous username and password for more information. If you do not like this account's new name, you can choose your own using this form after logging in: . -- Keegan (WMF) (talk) 04:44, 19 April 2015 (UTC)

title: User talk:CaladSigilon~enwikibooks


text:
Category:Book:Japanese

Guidelines, discussions, etc. should be go in /meta.

Add modules to this category by placing somewhere on the page.

fr:Catégorie:Japonais ja:Category:日本語 pt:Categoria:Japonês

title: Category:Book:Japanese


text:
Japanese/Lessons/Na-adjectives

There are two types of adjectives in modern Japanese: な- and い-adjectives. Both are descriptive and modify nouns. They describe nouns and form predicates differently.

The な-adjectives (形容動詞, けいようどうし) conjugate with nouns by appending "〜な" before the following noun.

Watch and Listen
Listen to the teacher read the following phrases, or click to listen on your computer.

Vocabulary
Nouns

な-adjectives

な-Adjective Predicates
When used as predicates, な-adjectives behave just like nouns:

Examples:

Note that the pronouns are usually dropped when they can be inferred from context. The pronouns in the English version are examples only to make better formed English sentences. For example, "だ" can mean any of: "I'm well," "He's well," "They're well," etc.

な-Adjectives noun modifiers
When preceding a modified noun, な-adjectives take a "な" before the noun:

Examples:

Practice
Try writing and speaking out the following sentences in Japanese:

Formal Japanese
 * 1) I am well.
 * 2) He is bright.
 * 3) She is famous.
 * 4) That is simple.
 * 5) She is a pretty woman.
 * 6) He is a healthy man.
 * 7) This is an important class.
 * 8) They are bright students.

Informal Japanese
 * 1) He is famous.
 * 2) She is well.
 * 3) They are bright.
 * 4) This is important.
 * 5) He is a handsome man.
 * 6) She is an important person.
 * 7) This is a tidy classroom.
 * 8) They are healthy students.

Other ideas for practice include:
 * Write な-adjectives on pieces of paper along with nouns and keep these in separate stacks. Pick one of each and say the sentence.
 * Now write the English on the other side and repeat, this time translating as well.
 * Make pictures to represent the sentences and drill with those.
 * Write a short story or describe something that happened to you.

If you need help gathering adjectives, you can search for lists on smart.fm. To check your story, you can post it on Lang-8.

title: Japanese/Lessons/Na-adjectives


text:
User talk:66.213.79.2

Hi! Thanks for your info on web crawler, but it doesn't really belong here. Check out Wikipedia and see if you can find a page there you could add your info to. Tango 17:08, 23 December 2005 (UTC)

title: User talk:66.213.79.2


text:
User talk:ManuelGR/Centralized development status proposal

This seems like a good idea. I would have preferred colon convention ("Template:Ada Programming:Development" instead of Template:Ada Programming/Development) because slash suggests subpages, but there is no "Template:Ada Programming" that it is a subpage of. (see below --Kernigh 08:01, 24 January 2006 (UTC)) However, slash convention seems useful.

Many books are linked from at least two places (such as Miscellaneous bookshelf and Template:Miscellaneous bookshelf). Thus, I would find centralised stages useful. If there are no major changes to these templates soon, then I will create Template:Guide to X11/Development (for Guide to X11) and some others. --Kernigh 19:06, 23 December 2005 (UTC)

 * I don't mind whether we use slash or colon for the convention of the templates. I proposed slash because this is the convention used in es: but given that there we are using the main namespace, the superpage does indeed exist. But using the main namespace has other problems, so I think Template: should be used and consequently colon can be useful for avoiding the confusion with the subpage convention used in the main namespace. I would like to know what other people think about it before changing the template. ManuelGR 18:40, 24 December 2005 (UTC)

The colon convention used for templates seems to conform better with WB:NP. There is a problem with your solution. As Kernigh points out, stage information is used in at least two places such as Miscellaneous bookshelf and Template:Miscellaneous bookshelf. Trouble is, Miscellaneous bookshelf would use while Template:Miscellaneous bookshelf would use. I haven't looked very hard, but I don't see an good way to use stage information from a single place that would also give you a choice between and. The following would work:

 * |&nbsp;

where the Template:Book_name:Development is something like:

However, this is undesirable in two important respects.

 * 1. It requires the user of the template to supply a parameter for .  One possible but somewhat ugly cure would split your template into two versions:  a three parameter version as above and the following two parameter one:

 * &nbsp;

 * 2. It requires a more complicated Template:Book_name:Development that some contributors won't get right.

Well, perhaps it's best just to apply the KISS principle and stick with your proposal (though I still favor the colon convention in templates for compliance with WB:NP). --JMRyan 23:39, 23 January 2006 (UTC)

 * I had preferred colons, but the problem is that the syntax to include "Template:Ada Programming:Development" would be, which would cause confusion with the syntax for transcluding pages outside the "Template:" namespace. For example, I when I created , it used the Wikibooks, not Template, namespace. (I moved "Wikibooks:Template messages:toc" to Template:Template messages. --Kernigh 04:59, 30 January 2006 (UTC)) In fact, if someone created "Template:Cookbook:Development", the syntax  would probably fail because Cookbook is now a namespace.

 * However, "Template:Cookbook/Development" continues to seem bad because of the mixed colons and slashes... --Kernigh 08:01, 24 January 2006 (UTC)


text:
Haskell/Classes and types

Back in Type basics II we had a brief encounter with type classes as the mechanism used with number types. As we hinted back then, however, classes have many other uses.

Broadly speaking, the point of type classes is to ensure that certain operations will be available for values of chosen types. For example, if we know a type belongs to (or, to use the jargon, instantiates) the class, then we are guaranteed, among other things, to be able to perform real division with its values.

Classes and instances
Up to now we have seen how existing type classes appear in signatures such as:

Now it is time to switch perspectives. First, we quote the definition of the  class from Prelude:

The definition states that if a type  is to be made an instance of the class   it must support the functions   and   - the class methods - both of them having type. Additionally, the class provides default definitions for  and   in terms of each other. As a consequence, there is no need for a type in  to provide both definitions - given one of them, the other will be generated automatically.

With a class defined, we proceed to make existing types instances of it. Here is an arbitrary example of an algebraic data type made into an instance of  by an instance declaration:

And now we can apply  and   to   values in the usual way:

A few important remarks:

 * The class  is defined in the Standard Prelude. This code sample defines the type   and then declares it to be an instance of  .  The three definitions (class, data type, and instance) are completely separate and there is no rule about how they are grouped. This works both ways: you could just as easily create a new class   and then declare the type Integer to be an instance of it.

 * Classes are not types, but categories of types, and so the instances of a class are types instead of values.

 * The definition of  for   relies on the fact that the values of its fields (namely   and  ) are also members of  .  In fact, almost all types in Haskell are members of Eq (the most notable exception being functions).

 * Type synonyms defined with type keyword cannot be made instances of a class.

Deriving
Since equality tests between values are commonplace, in all likelihood most of the data types you create in any real program should be members of Eq. A lot of them will also be members of other Prelude classes such as Ord and Show. To avoid large amounts of boilerplate for every new type, Haskell has a convenient way to declare the "obvious" instance definitions using the keyword deriving. So, Foo would be written as:

This makes <tt>Foo</tt> an instance of <tt>Eq</tt> with an automatically generated definition of <tt>==</tt> exactly equivalent to the one we just wrote, and also makes it an instance of <tt>Ord</tt> and <tt>Show</tt> for good measure.

You can only use <tt>deriving</tt> with a limited set of built-in classes, which are described very briefly below:

 * Eq : Equality operators <tt>==</tt> and <tt>/=</tt>

 * Ord : Comparison operators <tt>< <= > >=</tt>; <tt>min</tt>, <tt>max</tt>, and <tt>compare</tt>.

 * Enum : For enumerations only. Allows the use of list syntax such as <tt>[Blue .. Green]</tt>.

 * Bounded : Also for enumerations, but can also be used on types that have only one constructor. Provides <tt>minBound</tt> and <tt>maxBound</tt> as the lowest and highest values that the type can take.

 * Show : Defines the function <tt>show</tt>, which converts a value into a string, and other related functions.

 * Read : Defines the function <tt>read</tt>, which parses a string into a value of the type, and other related functions.

The precise rules for deriving the relevant functions are given in the language report. However, they can generally be relied upon to be the "right thing" for most cases. The types of elements inside the data type must also be instances of the class you are deriving.

This provision of special "magic" function synthesis for a limited set of predefined classes goes against the general Haskell philosophy that "built in things are not special", but it does save a lot of typing. Besides that, deriving instances stops us from writing them in the wrong way (an example: an instance of  such that   would not be equal to   would be flat out wrong).

Class inheritance
Classes can inherit from other classes. For example, here is the main part of the definition of <tt>Ord</tt> in Prelude:

The actual definition is rather longer and includes default implementations for most of the functions. The point here is that <tt>Ord</tt> inherits from <tt>Eq</tt>. This is indicated by the <tt>=></tt> notation in the first line, which mirrors the way classes appear in type signatures. Here, it means that for a type to be an instance of <tt>Ord</tt> it must also be an instance of <tt>Eq</tt>, and hence needs to implement the <tt>==</tt> and <tt>/=</tt> operations.

A class can inherit from several other classes: just put all of its superclasses in the parentheses before the <tt>=></tt>. Let us illustrate that with yet another Prelude quote:

Standard classes
This diagram, adapted from the Haskell Report, shows the relationships between the classes and types in the Standard Prelude. The names in bold are the classes, while the non-bold text stands for the types that are instances of each class (<tt>(->)</tt> refers to functions and <tt>[]</tt>, to lists). The arrows linking classes indicate the inheritance relationships, pointing to the inheriting class.

Type constraints
With all pieces in place, we can go full circle by returning to the very first example involving classes in this book:

is a type constraint, which restricts the type  to instances of the class. In fact,  is a method of , along with quite a few other functions (notably,   and  ; but not  ).

You can put several limits into a type signature like this:

Here, the arguments <tt>x</tt> and <tt>y</tt> must be of the same type, and that type must be an instance of both <tt>Num</tt> and <tt>Show</tt>. Furthermore, the final argument <tt>t</tt> must be of some (possibly different) type that is also an instance of <tt>Show</tt>. This example also displays clearly how constraints propagate from the functions used in a definition (in this case,  and  ) to the function being defined.

Other uses
Beyond simple type signatures, type constraints can be introduced in a number of other places:

 * declarations (typical with parametrized types);

 * declarations (constraints can be introduced in the method signatures in the usual way for any type variable other than the one defining the class );

 * declarations, where they act as constraints for the constructor signatures.

A concerted example
To provide a better view of the interplay between types, classes, and constraints, we will present a very simple and somewhat contrived example. We will define a  class, a   class which inherits from it, and a function with a   constraint implemented using the methods of the parent class, i.e..

A word of advice
Do not read too much into the  example just above; it is merely a demonstration of class-related language features. It would be a mistake to think that every single functionality which might be conceivably generalized, such as, needs a type class of its own. In particular, if all your  instances should be able to be moved as well then   is unnecessary - and if there is just one instance there is no need for type classes at all! Classes are best used when there are several types instantiating it (or if you expect others to write additional instances) and you do not want users to know or care about the differences between the types. An extreme example would be : general-purpose functionality implemented by an immense number of types, about which you do not need to know a thing before calling. In the following chapters, we will explore a number of important type classes in the libraries; they provide good examples of the sort of functionality which fits comfortably into a class.

title: Haskell/Classes and types


text:
Geometry/Appendix B

Section 2.3 - Using Proofs in Geometry
1.

 * Angle 2 = 120 degrees since it is supplementary to angle 1. Supplementary angles are any two angles whose sum is 180 degrees.
 * Angle 3 = 60 degrees since
 * Angle 1 and Angle 3 are vertical angles. Vertical angles are two nonadjacent angles formed by two intersecting lines.
 * Angle 4 = 120 degrees since it is supplementary to angle 1.
 * Angle 5 = angle 1 by the Transversal Postulate.
 * Angle 6 = angle 2, angle 7 = angle 3, and angle 8 = angle 4 by the Transversal Postulate.

2.

 * Angle 2 = angle 3 is given
 * Lines R and S are parallel by the Alternate Interior Angles Converse Postulate

Section 5.1 - Methods of Proving that Triangles are Congruent
1. Yes; triangle RUN = triangle DIH by ASA

2. No; the sides and angles do not match

3. Yes; triangle SUM = triangle HRC by ASA

4. Yes; triangle QWE = triangle TYR by SSS

title: Geometry/Appendix B


text:
Talk:US Patent Law

Note: regarding the key components of a patent, isn't the specification the key component. Technically the specification contains the claims as well as the description of the invention. That's what I read at the USPTO MPEP site.

Also, I believe there are a number of other defenses that can be listed under "Defenses" to infringement- for instance, contending that the patent is invalid becaue of a 102b bar or the disovery of additional prior art.

1 yr clock for novelty or not?
The novelty text reads: "So when a magazine is sent to subscribers or a dissertation is shelved in a library, the one-year clock begins for any inventions described therein.", but the description says nothing about a 1 year clock. Which of the two is wrong? Irrevenant 10:45, 9 January 2006 (UTC)

I believe that this question is old, and the text of the novelty section already clarifies this point. However, to be certain, here goes: the "1 year clock" means that publication of an invention is not an absolute bar to filing a patent application in the United States. An inventor (meaning either the author of the publication or someone who came up with the invention before the author thought of it) can still file a patent application within one year of the publication. However, any patent application filed more than one year after publication of an invention should not be issued as a patent, and any such mistakenly issued patent is invalid. --Adubberley 01:34, 12 September 2006 (UTC)

100%
how is this article marked as 100%? it's nowhere near close to that.--Aosik 17:45, 7 July 2007 (UTC)

First to Invent
This book is out of date and needs to be updated. Particularly, in the book is stated that "In the United States, a patentee must be the first to invent." However, the United States changed from a first-to-invent system to a first-to-file system in 2013.--Skorovs (discuss • contribs) 00:40, 6 April 2014 (UTC)

title: Talk:US Patent Law


text:
Policy Debate/Basic Format

The format of Policy-Debate as designed by the National Forensic League (NFL) is a series of alternating speeches between the affirmative team and the negative team. Generally the time limits described below are pretty universal, only the time of cross-examination is usually altered.

8 - First Affirmative Constructive

3 - Cross-Examination (2N)

8 - First Negative Constructive

3 - Cross-Examination (1A)

8 - Second Affirmative Constructive

3 - Cross-Examination (1N)

8 - Second Negative Constructive

3 - Cross-Examination (2A)

5 - First Negative Rebuttal

5 - First Affirmative Rebuttal

5 - Second Negative Rebuttal

5 - Second Affirmative Rebuttal

As is should be, the Affirmative has the final word in the debate, because after all, the decision of the judge relies on the infallibility of the Affirmative proposal, or the Negative's interpretation and demonstration of the fallible parts of the Affirmative proposal under the resolution.

title: Policy Debate/Basic Format


text:
User talk:80.68.2.41

You have been temporarily blocked from editing Wikibooks. You were warned several times that linking to commercial sites is not allowed. If you wish to make useful contributions, you are welcome to come back after the block expires.

title: User talk:80.68.2.41


text:
Policy Debate/Stock Issues

The meat of a policy debate comes from the stock issues. To easily remember the stock issues, debaters often use the acronym "SHITS."

 * Significance : How significant is the problem that you are trying to remedy through your interpretation of the resolution?

 * Harms : What happens if your plan doesn't pass; why is your plan needed right now?

 * Inherency : What is inherent in the status quo that prevents your problem from already being solved?

 * Topicality : Does your case fall within the topic? Does your case meet the parameters of the resolution?

 * Solvency : Does your plan actually solve the problem?

title: Policy Debate/Stock Issues


text:
Template:Guide to Unix/Commands

General: Introduction | Explanations | Why Unix-like

Platforms: Linux | BSD

Quick Reference: Commands | Environment Variables | Files | License Commands : Getting Help | File System Utilities | Finding Files | Devices | File Viewing | File Editing | Text Processing | File Compression | File Analysing | Multiuser Commands | Self Information | System Information | Process Management | Kernel Commands | Miscellaneous | SW Development |

title: Template:Guide to Unix/Commands


text:
User talk:67.86.32.131

Welcome
Hello and welcome to Wikibooks!

Here are some tips to help you get started:
 * You can sign your name on Talk and vote pages using four tildes, like this: ~~~~.
 * Remember to conduct any editing experiments in the sandbox.
 * Check out our help page if you need additional help.
 * Eventually, you might want to read the Manual of Style and Policies and Guidelines.
 * Templates can save your time
 * Remember to maintain a Neutral point of view.
 * Explore, be bold in editing pages, and have fun!

You will find more resources in Community Portal. If you want to ask a question, visit the Study help desk, the Staff lounge, or ask me personally on my talk page.

Good luck!

Good work with Paper Mario: The Thousand-Year Door! --Gerard Foley 23:02, 23 December 2005 (UTC)

title: User talk:67.86.32.131


text:
User talk:85.97.135.145

You have been temporarily blocked from editing Wikibooks. You were warned several times that linking to commercial sites is not allowed. If you wish to make useful contributions, you are welcome to come back after the block expires.

title: User talk:85.97.135.145


text:
User:Drn8~enwikibooks

Drn8

My wikipedia contributions

My wikibooks contributions

title: User:Drn8~enwikibooks


text:
Outdoor Survival/Quinzhee

A quinzhee is a type of snow shelter made by making a pile of snow, waiting for it to settle together, then hollowing out the inside. In contrast, an igloo is made by carefully stacking cut blocks of snow.

Design principles
It is not difficult to make a quinzhee, though it will be warmer and stronger if certain techniques are carefully followed and on that note, make sure you live in an area with snow, or this will have little use to you, a stupid wikibook, right?. For strength, the quinzhee needs to be a dome and the lower walls must not need to support too much weight. The walls should be very thick at the base and get slightly thinner towards to the top of the dome.

For warmth, the entrance of the quinzhee should be a tunnel with an upward sloping floor such that the floor is slightly higher than the top of the entrance. Be careful not to increase the height of the door by hitting it with your back each time you enter! And DO NOT bring a heater in with you, or the structure might melt on you.

How to build a quinzhee
To make a quinzhee, make a large dome of snow. When making the pile, consider the inside shape that you want. A quinzhee to sleep two should have an oval footprint. Remember to make it high enough so that the floor can be elevated. Placing it on a hill can help with this. The length needs to be the wall thickness plus the length of your sleeping bag.

Once the pile is done, insert sticks straight in to a depth of 30 cm. As you dig it out, these sticks will tell you when you are near the outside so that you won't dig through. Wait for an hour or two for the snow to settle. The snow will re-form into a hard material that will not fall in when it is dug out.

Dig out the quinzhee with a small shovel. The fastest way is to cut blocks and push those towards the door. Cut the blocks left, right, top, and bottom. Don't pry too much as this can create cracks in the wall. As you get further in, it will be helpful to have a person outside moving the snow out of the tunnel and away. Eventually, two people will be able to fit inside and the digging goes much faster.

title: Outdoor Survival/Quinzhee


text:
Talk:Outdoor Survival/Quinzhee

Created
I created this module from the quinzhee article in Wikipedia, which at the time was just a how-to. There, I am w:user:Tysto. --12.207.74.83 00:10, 24 December 2005 (UTC)

title: Talk:Outdoor Survival/Quinzhee


text:
Mac OS X Tiger/Meet the Applications/QuickTime

=Introduction= QuickTime, Apple's media player, is widely considered to be one of the "big three" audio/video players available. The other two, Microsoft's Windows Media Player and Real Media's Real Player, are also available for the Mac, but are not included out of the box.

QuickTime files are actually just digital "shells" containing two different files: an audio file and a video file. This provides content makers with a huge amount of flexibility.

=QuickTime Player= =QuickTime Pro=


text:
Muggles' Guide to Harry Potter/Magic/House Elf

Overview
House-elves are small creatures with big eyes and bat-like ears, and are usually very poorly clothed. They can often be found at large houses and mansions. They are supposed to be very loyal to the head of their family. An owner or master can 'free' a house elf by giving him or her clothes.

Extended Description
House-elves are essentially slaves – they will serve one family for a long part of their life, and they feel that this is right and proper, that this is what they were created to do. At Hogwarts there are hundreds of house-elves, preparing the food for the feasts, cleaning, and doing other chores. House-elves are bound to listen to members of the family they belong to, but can choose to disobey anyone else. In extraordinary circumstances, they can even disobey their masters, but afterwards they will punish themselves quite harshly for it. Three house-elves play a significant role in the books: Dobby, Winky, and Kreacher; a fourth one, Hokey, is mentioned (in Harry Potter and the Half-Blood Prince, where she serves Hepzibah Smith), but does not play a particularly significant role.

Analysis
Quite obviously, most house-elves are content with their status, and believe that their situation, caring for their owners in return for shelter and, presumably, food, is right and proper. In fact, house-elves are considered chattel in the Wizarding world, and presumably could be sold; while we never see this, we do note that at Sirius' death, Kreacher is apparently included as being part of the house and property which Harry inherits. Kreacher has no say in this, he very strongly resists becoming the slave of one he considers a Mudblood, but he must, all the same, obey Harry's orders. We cannot know whether there is a magical component to Kreacher's transference of allegiance, but Professor Dumbledore sees it as proof that ownership of Sirius' house has passed to Harry. This suggests, first, that magic is involved, rather than simply tradition; and second, that Kreacher is considered a part of the house, and thus property rather than an individual.

House-elves can be freed; giving a house-elf clothes frees it from its situation, which is why they are so ill-clothed. They must wear whatever castoffs they can scavenge, which results in many of them wearing things like discarded, damaged pillowcases and rags twisted into rude loincloths. Most house-elves, however, do not want to be freed, and resist the suggestion most strongly. One exception is Dobby, who was the house-elf of the Malfoy family; he was so ill-treated there that he rebelled and eventually left their employ when Harry managed to engineer his receiving a sock from his master, Lucius Malfoy. As a free house-elf, Dobby was unable to find work for a year or so, eventually joining the kitchen staff at Hogwarts; it seems that most wizards don't want house-elves that they have to pay for, even if it is only a Galleon per month.

When Winky is dismissed in Harry Potter and the Goblet of Fire, Dobby manages to get her employed at Hogwarts as well; however, she doesn't want to work, she simply sits, mourning the loss of her position and drinking herself to oblivion, for almost a year. She has not directly appeared in any of the books since then, though Dobby does mention her again in the next book.

Hermione tries to start up an organization to combat this apparent slavery, the Society for the Promotion of Elfish Welfare (S.P.E.W.), but quite apart from the unfortunate acronym, she meets a substantial amount of resistance, not only from wizards and witches who like having house-elves around to serve them, but from the house-elves themselves who prefer security to freedom. Hermione's attempts to emancipate the Hogwarts house elves, by hiding clothing under garbage in the Gryffindor common room where elves will pick it up, is seen as insulting by the elves; they understand dismissal as a sign of completely failing their master or family. Hermione's effort would be ineffective, even if the elves did not react by shunning Gryffindor tower, leaving Dobby the job of cleaning Gryffindor by himself. It is only an elf's master who can free him by giving him clothes, which means Albus Dumbledore, or possibly one of the staff, but the students are not in a position of authority over the elves.

Hermione may have been misled in her efforts by Harry's recounting of how Dobby gained his freedom. It was Harry's sock, originally, but Harry had given it to Lucius Malfoy, and it was Lucius who had inadvertently given it to Dobby. Harry understood, as Hermione apparently does not, that if Harry had given the sock to Dobby directly, it would not have freed him. Interestingly, Harry himself falls into this same mistake in the fifth book: seeing that Hermione has a gift for Kreacher, he cautions her about giving Kreacher clothes, forgetting that only Sirius, Kreacher's master, could free him.

House-elves have a tendency to over-simplify the language. They refer to themselves in the third person ("Dobby is most sorry, sir...") and use full names ("Dobby cannot let Harry Potter lose his Wheezy!"), both of which would seem to imply an uncertainty about the use of language – the intricacies of "I" versus "you", and the appropriate use of names and nicknames, seems to be beyond them. This would imply a lower level of verbal intelligence than humans have. Additionally, Dobby's efforts to prevent Harry from returning to Hogwarts, or to get him to return to Privet Drive once he is there, seem quite poorly thought out, almost child-like, again suggesting a less sophisticated level of intelligence. From this, one can see why a house-elf would be afraid to be freed; the world is a scary place for one so surrounded by people smarter than himself.

Questions

 * 1) How do house-elves do laundry?
 * 2) We see that house-elves are nominally male (e.g. Dobby) and female (e.g. WInky), so can assume some sort of reproduction. Given that house-elves normally live one to a household, how do they manage to marry (assuming marriage – this is a child's book after all) and raise families?

Greater Picture
The intellect of house elves is probably best described as "child-like". This is telegraphed to us by their use of language; specifically, the confusion of "I" and "you", and the misuse of full names and nicknames, is characteristic of the very young. In Harry Potter and the Chamber of Secrets, we also see that Dobby's attempts to prevent Harry's return to Hogwarts, and to send him home once he is back at school, are quite childish. The same is true of Kreacher's loyalty. When we first see him, Kreacher is plainly rebelling, in a sullen and childish manner, against the orders of a Master he feels is unworthy. Circumstance has made it necessary for him to accept Sirius' orders; nothing will make him like it, and he will resist every way he can. Kreacher behaves the same way when Harry becomes his Master in Harry Potter and the Half-Blood Prince. In the same book, we see a direct contrast between Kreacher's barely-below-the-surface rebellion, and Dobby's enthusiastic loyalty, when the two of them are assigned the same task by Harry.

It is because of this perceived child-like intelligence that we are able to accept Kreacher's sudden change of loyalty when Harry enlists his aid to retrieve Mundungus Fletcher and the locket Kreacher had been instructed to destroy. The very young are able to form very sudden and deep alliances for what seem quite trivial reasons, and Kreacher's response to Harry actually caring about the same things Kreacher cares about would be characteristic of this. Ron's caution that Harry was "over the top" when he gave Regulus' locket to Kreacher was not accurate; although it did result in Kreacher falling apart emotionally, it was necessary so that he could reassemble, centered around Harry, rather than around Sirius' mother.

The status and situation of house elves is complicated. Applying human values to "help" non-humans is not as straightforward as some, including Hermione, believe at first. Hermione's campaign with S.P.E.W. is laudable and correct, elves are slaves and should be given the rights, privileges and respect humans enjoy. However, she finds difficulty in understanding the values and desires of most elves. Initially she wishes to free all elves and have them paid wages for their work. The elves, with few exceptions, consider this an insult to their honor. Elves appear to have been bred or enchanted to view their servitude as a noble vocation rather than enslavement. This breeding and enchantment is obviously the selfish work of wizards in the far past who desired the luxury of dedicated servants who cost nothing. Such a tradition, as Hermione finds out, is difficult to reform and requires some patience. Eventually the elves, including Kreacher, achieve some enlightenment, and the victory banquet at the end of Harry Potter and the Deathly Hallows is shared by elves, humans and others as friends and (at least temporarily) equals.

Not mentioned above is the apparent fact that House Elf magic is not of the same type as human magic. In particular, we are told numerous times that Hogwarts is protected against Apparition, that you cannot Apparate into or out of Hogwarts, or even within Hogwarts except when the spells are locally and temporarily lifted in the Great Hall for Apparition class. Yet, Dobby is clearly able to Disapparate from Harry's grip in the Hospital Wing; we see that in Harry Potter and the Chamber of Secrets. This shows that House Elf Disapparition is different from "wand-bearer" Disapparition in two respects: first, it can be done in places where the human spell is blocked, and second, it can be used to get away from someone who is holding the caster, something that evidently is not so easily accomplished by humans.

This ability of House Elves to Apparate where humans cannot plays a fairly important role later in the series as well. Kreacher, taken to the cave of the locket, is able to return to the Black house and tell Regulus what had happened, despite Voldemort having surrounded the location with various protective and preventative spells, and despite Kreacher's then being dragged underwater by Inferi. It is Kreacher's information that leads Harry to a Horcrux.

Whether other House Elf magic is significantly different from human magic is uncertain. We know that House Elves do not carry wands, and so there is certainly a difference in the way magic is produced; however, apparently House-Elf magic can be stopped by human magic, as Mundungus Fletcher is able to loot Grimmauld Place despite Kreacher's efforts to stop him.


text:
Cookbook:Wisconsin Ackawi Cheese Triangles

| Appetizers | US Cuisine | Midwestern U.S. Cuisine

Ackawi cheese triangles make use of a specialty cheese called ackawi.

Ingredients

 * 2 cups (8 ounces / 225 g) shredded Wisconsin Ackawi cheese
 * ½ cup (120 ml) chopped fresh parsley
 * ¼ cup (60 ml) chopped onion
 * 1 egg white, slightly beaten
 * ¼ teaspoon (1.25 ml) ground red pepper
 * 2 sheets frozen puff pastry,

Procedure

 * 1) Combine cheese, parsley, onion, egg white, and red pepper; set aside.
 * 2) On a lightly floured surface, roll 1 sheet pastry into a 12 x 12-inch (30 x 30 cm) square; cut into 16 ea. 3 x 3-inch (7.5 x 7.5 cm) squares.
 * 3) Place 1 tablespoon (15 ml) cheese mixture on each square; fold pastry over each filling, forming a triangle. Seal edges with tines of a fork; place on an ungreased baking sheet.
 * 4) Bake at 400°F (200°C) for 10 minutes or until golden brown. Repeat process with second sheet of puff pastry.
 * 5) Serve warm.


text:
Cookbook talk:Wisconsin Ackawi Cheese Triangles

I moved this recipe from Wikipedia, where it was part of the article on Ackawi cheese. I can't make any comment on how well this recipe works, or if it works with other cheeses. Any errors in copying from one wiki to the other are mine. Kerowyn 03:16, 24 December 2005 (UTC)


text:
Cookbook:Coconut Barfi

| Indian Cuisine | Dessert

Barfi is a Pakistani and Indian confection popular all over Pakistan and India, and often a part of festivals. The recipe included here is for coconut barfi.

Ingredients

 * 250 g sugar
 * 150 ml water
 * 250 g finely-grated coconut
 * Ghee
 * Ground cardamom (optional)

Procedure

 * 1) Combine sugar and water in a pot, and cook to a 2–3 thread (about 235–255°F) sugar syrup.
 * 2) Warm the coconut in a heavy saucepan, and pour in the hot syrup. Stir well, and cook until a soft lump forms.
 * 3) Press and spread the mixture into a ghee-greased pan or mold, and let cool.
 * 4) Sprinkle with cardamom.
 * 5) Cut into squares, and store in an airtight container.

title: Cookbook:Coconut Barfi


text:
GCSE Science/Radioactivity

A radioactive substance is one which has an unstable nucleus and gives out radiation to try to become stable. This is also known as radioactive decay. Radioactivity is a completely random process. This means that you cannot predict when an unstable nucleus will decay. It's completely unaffected by physical conditions such as temperature.

Radioactivity is defined as the spontaneous disintegration or decay of some elements with the emission of alpha, beta and gamma radiations.

Radioactive elements are elements that disintegrate by emitting radiations capable of ionising air molecules or any matter through which they pass. There are two types of radioactive elements – natural and artificial radioactive elements. The natural radioactive elements include uranium, radium, thorium, Plutonium. The artificial radioactive elements are cobalt-60, iodine-131, and sulphur-35.

title: GCSE Science/Radioactivity