OpenLLM-France/wikimedia huggingface dataset:
# Social psychology (psychology)/Discussion

* A key communication channel for this unit will be via an electronic discussion list: Social psychology discussion list(Google Groups). Uses of this list can include:
* Announcements, including notification of the availability of weekly guides, lecture notes, tutorial notes, assessment, etc.
* Questions and answers about any aspect of the unit.
* Discussion, collaboration, etc. amongst students of the unit.
How to join
Subscribe to the group using a Google Account.
If you don't already have one, create a Google Account using your student email address or your personal email address as your user name, or you can create a gmail account and use that email address.
User options
When you join the group, you can opt to receive:
One email per message
Daily digest
No email - just access on the web
Active contributors
This user is active on the social psych unit's discussion list.
Active contributors to the list may add this userbox to their e-porfolio page (using {{SPPP2008D}})
This will automatically add you to the list of active discussion list contributors. :
# Social psychology (psychology)/Assessment/Essay/Word count
### Word count

* There is no minimum length; maximum is 3000 words.
* Essays above the word count limit (3000 words) will incur a penalty (5% per 100 words).
* There is no 10% over allowance - if you need this, aim for 2,700 words!
* Word count = body text (i.e., all essay body text and in-text citations, but not title, abstract, tables, figures, references (i.e., the reference list), or appendices).

### Marking disputes

For anyone dissatisfied with the marking/grading and/or feedback received, please see these suggested steps: marking dispute process
# Social psychology (psychology)/Banner

| Support site for an on-campus Social Psychology unit at the University of Canberra, 2008, with learning materials which are free and open to all . | This is the homepage for Social psychology (psychology)/Banner. Subject classification: this is a psychology resource. Completion status: this resource is considered to be complete. Educational level: this is a tertiary (university) resource. Search for Social psychology (psychology) on Wikipedia. Wikibooks has a book on the topic of Social Psychology. Quality resource: this resource has been proposed for featuring on the main page of Wikiversity. |
# Social psychology (psychology)/Assessment/Essay/Topics/Signup

* Essay topic registration is open!
* What to do:
* Decide on your preferred topic.
* Then email the convener with your Wikiversity user name and your preferred topic → the convener will then add your Wikiversity name into the table of topics.
* If someone has already signed up for a topic you are interested in, you can still request that topic - but you should suggest an alternative, related question.
# Software Design/Extract Class

Extract Class is a general refactoring with several more specific instances which have varying positive effects but mostly the same drawbacks:
* Extract Wrapper Object aims at removing logic duplication in the code.
* Extract parts of a class into smaller classes improves code's robustness, clarity, apparency of semantics, testability, and reusability.
* Introduce Parameter Object aims at improving interface robustness.
This article corresponds to Extract Class refactoring described in Refactoring.

## Why not

Extracting a class contributes to pointer indirection that might slow down the software if objects of the extracted class are accessed frequently. It might also make the software to use more memory or spend more time in garbage collection in environments such as JVM (both effects are manifestations of higher resource usage) if a lot of objects of the extracted class are created.
Another disadvantage of this refactoring is that it spreads the logic over more locations that makes the readers to navigate more. See practice Don't break logic into too many small functions.

## Related

* Split responsibilities between classes and functions
* Extract loosely coupled parts of a class into smaller classes
# Software Design/Extract Wrapper Object

Extract Wrapper Object is a refactoring primarily aiming at removing logic duplication in the code as per DRY principle. Extract Wrapper Object is related to Extract Class and Introduce Parameter Object refactorings.

## Examples

If there is some code working with coordinates x and y and repeatedly performing operations such as negation:
The coordinates could be grouped into a Point object on which negate function can be defined:
For another example, there may be a class with several operations and in some cases some aspect should be attached to calling those operations, such as logging or notifying some listener:
Then a decorator class such as ListeneableContainer can be extracted to gather the repetition of the aspect's logic in one place:

## Related refactorings and practices

* Extract Class
* Don't repeat logic in several places
* Extract parts of a class into smaller classes

## Sources

* Refactoring: Improving the Design of Existing Code (2 ed.). 2018. ISBN 978-0134757599. https://martinfowler.com/books/refactoring.html. Chapter 3, "Data Clumps" section
# Software Design/Extract generic components
## Related

* Require the least powerful abstract class you need to implement a function
* Create pure functions

## Sources

* A Philosophy of Software Design, "Make code just a little generic"
* https://softwareengineering.stackexchange.com/questions/361605/should-the-solution-be-as-generic-as-possible-or-as-specific-as-possible
* http://degoes.net/articles/insufficiently-polymorphic
# Software Design/Glossary

This is a glossary of terms used in the Software Design research project. The primary terms shall be used for consistency across all pages in the project.
The terminology is not aligned with any single programming language, though it's biased towards terms used in object-oriented programming.
* Field: property, element
* Variable: field (in some contexts, variable may mean either a field, a parameter, or a local variable), property, constant, parameter, declaration
* Collection: container, array, data structure
* Function: method, procedure, routine, subprogram
* Anonymous function: lambda, closure
* Class: (data) structure, type, typeclass, interface (in some contexts, class may mean either a class or an interface), trait, component, source code file, component, page
* Exception: error, panic, failure
* Abstract class: interface (as in C#, Java, and Go; not to be confused with interface as a shared boundary between dependency and dependent software, and between software and its non-software users: humans and systems), class, (abstract) (data) type, typeclass, trait.
* Package: module, namespace, unit, source code directory. The term module is used more widely in modern programming languages than package, but it's avoided because in Java "module" means something different and therefore it may be confusing.
* Patch: pull-request
* API: a specific method prescribed by a computer operating system by which a software programmer while writing an application program can make requests of the operating system or another application.
# Software Design/How much navigation is needed while working with code

This is a code quality expressing the amount of navigation required from readers when they are working with code: how many times they need to jump between different declarations.

## Relevant practices

* Specify interface contracts
# Software Design/Interface robustness

Interface robustness is an interface quality which is very close to code robustness quality. Code robustness is largely defined by the robustness of all interfaces (in a wide understanding of interface: both API and the constructs of the programming language) used in the code. However, code robustness has some additional contributing factors other than interface robustness, such as how structured is the code, how big is it, etc.
Interface robustness (as defined in Software Design project) is different from interface reliability. A robust interface is hard or impossible to misuse. A reliable interface may be easy to misuse, but it continues to operate normally even if it is misused.

## Relevant practices

* Use class instead of primitive type
# Software Design/Link to a ticket from an unusual place in code

Checklist questions:
* Does a hack or workaround code for some bug has a comment including a link to the ticket describing this bug?
* Does a TODO comment link to the ticket tracking the corresponding task?
* Does temporary code have a comment with a link to a ticket or a relevant discussion where this code was justified if there is any?
* Is puzzling code (either due to unclear purpose or obscure semantics prepended with a comment with a link to a ticket or other resource providing some context or explanation if there is any?

## Why

Readers of unusually looking or bewildering code are more likely to want to obtain additional context. Extracting the context through browsing the editing history of the file through the VCS and finding to which pull request the relevant commit belongs is time-consuming, making the code harder to learn.
As URLs are quickly recognizable in the normal code, they catch the attention of code readers and developers who may have navigated to the code with a goal in mind unrelated to the subject unusual code. This may prompt them to check whether the subject hack, fixme, or temporary code is now eligible to be fixed, e. g. if the blocker bug in an upstream library has been fixed. Additionally, if too many such pieces of code with corresponding links accrue in the code for a class or a subsystem, this may become visually recognizable to people whenever they visit the code for the system. This would be a reminder for them to take time to fix some of these places with hacky code. These two effects may help the developers to keep the technical debt in control without requiring their explicit efforts (deliberate planning or tracking of these problems in code), and with less cognitive load.

## Why not

Links in comments catch the attention of the readers and thus making them to expend more mental efforts to keep the focus on their task at hand.
When the context of the issue is small so it can fit a comment spanning one or a few lines of code or could be summarized to this size, inserting a link instead of a plain text comment providing the context is an indirection which itself makes the semantics or the purpose of the unusual code less apparent due to the indirection and that the text describing the context and the code not directly adjacent. However, if providing the context would be a long comment and there are several places in the codebase where it is needed, putting such comments instead of just a link creates duplication and increases the total code size.
Linking to relevant tickets from normal business logic code (for example, a documentation comment for an ordinary class linking to the ticket in the context of which the class was added to the system) may be taking this practice too far in the first place because this may unnecessarily catch code readers' attention at too many places and be a poor substitute for writing proper documentation and comments.

## Related

* Comment non-obvious code
* Comment the flaws in the code
* Use TODO comments
* Avoid too long comments
# Software Design/Extract loosely coupled parts of a class into smaller classes

Checklist questions:
* Loosely coupled parts of the state in a class can be extracted into smaller classes?
* There is a cluster of functionality within a class unrelated to the class's primary responsibility?
There is a difference between this refactoring and practice Create classes with a single purpose: a class may have a single purpose on some level of abstraction, yet it may consist of loosely coupled parts. It may be possible to extract these parts as smaller classes on the lower level of abstraction.
This refactoring is a special case of Extract Class.

## Examples

Consider a class like the following:
AuxFoo may be factored out of Foo:
See another example of this refactoring on Extract Class catalog entry.

## Why

Extracting parts of class's logic and state into smaller classes reduces the scope of both the extracted fields and the fields that are left in the original class. Then it's harder to make a programming mistake by accessing a wrong field. Extracted classes can protect their state by allowing access only via functions which reduces the probability of erroneous modifications of their state.
The core logic of the original class may become clearer because it's not intermingled with the auxiliary logic. Also, the names of the fields and functions in the extracted class don't have to be prefixed (as in AuxFoo class in the example above) which also improves the code clarity.
With the core logic and auxiliary parts residing in a single class, it may not be apparent to readers whether the fact that these parts don't interoperate with each other (or interoperate in certain, well-defined ways) is an accidental property or something inherent to the design of the class.
Extracting independent logical parts into smaller classes may help to make the main class more easily testable. In the testing environment, the smaller classes may be replaced with mocks or another implementation (if the extracted class, AuxFoo in the example above, is turned into an interface) to verify the core logic in the original class.
Separating the core logic and the orthogonal parts of the logic between different classes may allow both the main class and the smaller classes to be reused in the future, even though there may be no need for that at the moment (otherwise practice Don't repeat logic in several places should be applied anyway).

## Related

* Extract Class
* Break up too large and complex functions
* Split responsibilities between classes and functions
* Extract self-contained pieces of logic as functions
# Software Design/Interface size

Interface size (or API size) is an interface quality characterizing the sheer number of interface elements: classes, functions, configuration parameters.
Another way of measuring interface size is measuring conceptual weight: the number and difficulty of concepts that developers must master in order to use the interface. By definition, conceptual weight is a direct proxy of the steepness of learning curve which is ultimately what important to minimize.

## Relevant practices

* Don't hide an object access chain
# Selenography/New Selenography:LQ27
## Overview

{{{annotations}}}

## Craters

| Name | Latitude | Longitude | maps | Diameter,km | Type |
| shortname | xxx | xxx | | xxx | simple |

## Standard features

| Name | Latitude | Longitude | maps | Diameter,km | Type |
| shortname | xxx | xxx | | xxx | simple |
# Self-determination theory
## Overview

Self-determination theory (SDT) consists of six related sub-theories that explain different aspects of motivation and psychological well-being based on organismic dialectic approach (Deci & Ryan, 2000):
* Cognitive evaluation theory (CET): Focuses on how external rewards and feedback influence intrinsic motivation, emphasising the role of autonomy and competence.
* Organismic integration theory (OIT): Provides a taxonomy of motivation which describes a spectrum from extrinsic to intrinsic motivation, highlighting the processes through which external motivations can become internalised.
* Basic psychological needs theory (BPNT): Explains that autonomy, competence, and relatedness are essential for psychological growth, well-being, and optimal functioning.
* Causality orientations theory (COT): Examines individual differences in motivational orientation, identifying three types: autonomy-oriented, control-oriented, and impersonally-oriented.
* Goal contents theory (GCT): Differentiates between intrinsic and extrinsic goals, noting how they impact well-being and motivation.
* Relationships motivation theory (RMT): Explores the importance of satisfying relationships and how they contribute to fulfilling the need for relatedness, thereby influencing motivation and well-being.

## Basic psychological needs

Basic psychological needs theory suggests that there are three important ingredients for psychological well-being and which foster intrinsic motivation:
* Autonomy - Having a sense of personal control over life circumstances
* Competence - Having sufficient skill and knowledge to handle life circumstances
* Relatedness - Having at least some warm, positive, supportive relationships

## Taxonomy

Deci and Ryan (2000)'s taxonomy of motivation describes a motivational spectrum that includes amotivation, four types of extrinsic motivation, and intrinsic motivation.
# Self-esteem

In psychology, the term “self-esteem” was first used by William James in 1890 which makes it one of the oldest concepts in the field. In addition, self-esteem is the third most frequently occurring theme in psychological literature (Rodewalt & Tragakis, 2003) and has already resulted in over 25,000 articles, chapters, and books refer to the topic (Mruk, 2006). Given such a long history, it is not surprising to find three major types of self-esteem definitions in the field. The original definition presents self-esteem as a ratio that is found by dividing one’s successes in areas of life that are important to a given individual by the failures in them, which is to say one's “success / pretensions” (James, 1983/1890). A problem with this approach is that making self-esteem contingent upon success means that it is inherently unstable because failure can occur at any moment (Crocker and Park, 2004). In the mid 1960s Maurice Rosenberg and other social learning theorists defined self-esteem in terms of a stable sense of personal worth that can be measured by self-report testing. This definition became the most frequently used one in the field. However, now it is known that feeling good about oneself in healthy ways is difficult to differentiate from such things as narcissism (Baumeister, Smart, & Boden, 1996). Nathaniel Branden (1969) incorporated both elements of self-esteem when he defined it as a relationship between an individual’s competence and worthiness, especially in regard to how one handles the challenges of living when confronted by them. Research self-esteem based on this definition may be less prone to the limitations of the other approaches (Gecas & Schwalbe, 1893; Tafarodi & Milne, 2003). It is very important to realize when dealing with self-esteem that, although some definitions have been used more often than others in the field, each one is supported by a distinct body of quantitative as well as qualitative research and findings. Therefore, all of these approaches must be accounted for in any comprehensive understanding of self-esteem (Mruk, 2006).
# Selenography/New Selenography:LQ25
## Overview

{{{annotations}}}

## Craters

| Name | Latitude | Longitude | maps | Diameter,km | Type |
| shortname | xxx | xxx | | xxx | simple |

## Standard features

| Name | Latitude | Longitude | maps | Diameter,km | Type |
| shortname | xxx | xxx | | xxx | simple |
# Selenography/New Selenography:LQ28
## Overview

{{{annotations}}}

## Craters

| Name | Latitude | Longitude | maps | Diameter,km | Type |
| shortname | xxx | xxx | | xxx | simple |

## Standard features

| Name | Latitude | Longitude | maps | Diameter,km | Type |
| shortname | xxx | xxx | | xxx | simple |
# Selenography/New Selenography:LQ29
## Overview

{{{annotations}}}

## Craters

| Name | Latitude | Longitude | maps | Diameter,km | Type |
| shortname | xxx | xxx | | xxx | simple |

## Standard features

| Name | Latitude | Longitude | maps | Diameter,km | Type |
| shortname | xxx | xxx | | xxx | simple |
# Selenography/New Selenography:LQ26
## Overview

{{{annotations}}}

## Craters

| Name | Latitude | Longitude | maps | Diameter,km | Type |
| shortname | xxx | xxx | | xxx | simple |

## Standard features

| Name | Latitude | Longitude | maps | Diameter,km | Type |
| shortname | xxx | xxx | | xxx | simple |
# OpenStax University Physics/V1/Ch 13 P 37: torque

Not every item in a professor's bag of tricks needs to be introduced to students, but the line of action concept can be used to present the reader with a visually convincing argument that the calculation shown in the appendix is correct for the following problem from Volume I of CNX University Physics:
Chapter 12 Problem 37:
To get up on the roof, a person (mass 70.0 kg) places a 6.00-m aluminum ladder (mass 10.0 kg) against the house on a concrete pad with the base of the ladder 2.00 m from the house. The ladder rests against a plastic rain gutter, which we can assume to be frictionless. The center of mass of the ladder is 2.00 m from the bottom. The person is standing 3.00 m from the bottom. Find the normal reaction and friction forces on the ladder at its base.

## Verifying the Python-generated solution

The next section shows the Python code used to solve the problem for the parameters given in the textbook. Here we use the result of that calculation, which is that the force of friction at the base is $f=m_{eff}\cdot g$ where:
    $f=132.8\,N$
    $m_{eff}=13.55\,kg$
The 6-m long ladder is depicted in the center of this figure. The 2-m base, as well as the locations of the person (p) and ladder's center of gravity (l) are indicated. The short blue arrows (not to scale) represent the directions of the forces. The normal force at the wall, as well as the two weights are depicted, but the reaction forces at the bottom are not shown because they are easily deduced from the forces shown: the vertical component equals the net weight and the horizontal component (friction) is cancelled by the normal force.
The blue dashed lines display the lines of force, which are used to identify the length of the lever arms, which are shown in red. The moment arms for the normal force (n), ladder (l) and person (p) are easily verified from the to be approximately 5.67, 0.67, and 1.0 meters, respectively, as shown by the solid red lines in the central figure.
The three forces are shown in blue as the length of one side of the three yellow rectangles. Since the mass of the person and ladder were given in kg (70 and 10 respectively), it is convenient to express the force of friction as an effective mass: 13.55 kg. It is easily verified both visually and by arithmetic that the figure is consistent with the areas associated with the vertical "forces" (70-kg and 10-kg kg) being equal to the area associated with the normal "force" of 13.55-kg. Hence we conclude that the calculated answer seems to be correct.

## Appendix: Python calculation

This Python not only solves the problem for the parameters stated in the textbook, it also generates a series of similar problems with different parameters in LaTeX markup. Only the portion of the program that needs to be edited by authors is shown. Students not familiar with LaTex and/or Python can generate a CSV file using another programmable language (or even a spreadsheet). The question can be stated is simple text. The CSV table needs only generate the input and output values, and converting the question ascii text form into LaTeX markup is a simple task.
8700
# OpenStax University Physics/V1

The following links contain equations for the first volume of OpenStax University Physics

## Subpages

Special:Prefixindex/OpenStax University Physics/V1/