OpenLLM-France/wikimedia huggingface dataset:
# Primary mathematics/Activities/Three block towers

Three block towers is a primary mathematics activity for ages 5-11. This is a basic introduction to combinatorics. To do the three block tower you will need 18 blocks, 6 of three different colours. Older children may be able to do 4 blocks and also graph their results. If you don't have enough blocks of the same colour, you can use the printables on the NRICH website to colour them in instead.

## Materials

* 18 Blocks, LEGO, DUPLO or similar, 6 each of one colour. (I.e. 6 blue blocks, 6 yellow blocks, and 6 red blocks.)

## Directions

How many different towers can you make with three blocks using one of each of the three colours?
How many different towers can you make with two blocks using one of each of two colours?
What about only one colour? Or four colours?
Graph your results!
# Primary Science Experiments/Melting ice cube experiment/Melting ice cube experiment

See how fast ice cubes melt in hot and cold water! This experiment is intended for pre-k students and is appropriate for ages of 3-5.

## Materials

* Two glass cups
* Hot and cold water
* Two ice cubes
* stopwatch (optional)

## Form a hypothesis

Will an ice cube melt faster in hot water or cold water?

## Experiment

Get two clear glasses of the same size. Fill one glass halfway up with cold water. Fill the second one half way up with hot or boiling water.
Drop an ice cube in each glass. Optional: Start a timer.
Watch the ice cubes melt. If you are using a timer, write down the time at which the ice cube in each glass melts.

## Replication

Optional: Repeat the experiment. Each time you run the experiment, this is called a "trial."

## Results

Which ice cube melted faster? Was your hypothesis correct?
If you did multiple trials, were your results exactly the same?
# Primary Science Experiments/Melting ice cube experiment/Melting ice cube experiment/script

See how fast ice cubes melt in hot and cold water! This experiment is intended for pre-k students and is appropriate for ages of 3-5.

## Materials

* Two glass cups
* Hot and cold water
* Two ice cubes
* stopwatch (optional)

## Form a hypothesis

Will an ice cube melt faster in hot water or cold water?

## Experiment

Get two clear glasses of the same size. Fill one glass halfway up with cold water. Fill the second one half way up with hot or boiling water.
Drop an ice cube in each glass. Optional: Start a timer.
Watch the ice cubes melt. If you are using a timer, write down the time at which the ice cube in each glass melts.

## Replication

Optional: Repeat the experiment. Each time you run the experiment, this is called a "trial."

## Results

Which ice cube melted faster? Was your hypothesis correct?
If you did multiple trials, were your results exactly the same?
# Primary Science Lessons/Make Sun S'mores
## Harness the energy of the Sun to make the best snack ever invented.

Yummmmm! A solar oven is a box that traps some of the Sun’s energy to make the air inside the box hotter than the air outside the box. In other words, the solar oven is like a super greenhouse.

## You will need:

* Cardboard box with attached lid. Lid should have flaps so that the box can be closed tightly. Box should be at least 3 inches deep and big enough to set a pie tin inside.
* Aluminum foil
* Clear plastic wrap
* Glue stick
* Tape (transparent tape, duct tape, masking tape, or whatever you have)
* Stick (about 1 foot long) to prop open reflector flap. (Use a skewer, knitting needle, ruler, or whatever you have.)
* Ruler or straight-edge
* Box cutter or Xacto knife (with adult help, please!)

## How to make solar oven:

CAUTION: Have an adult cut the box with the box cutter or blade.
* Using the straight edge as a guide, cut a three-sided flap out of the top of the box, leaving at least a 1-inch border around the three sides.
* Cover the bottom (inside) of the flap with aluminum foil, spreading a coat of glue from the glue stick onto the cardboard first and making the foil as smooth as possible.
* Line the inside of the box with aluminum foil, again gluing it down and making it as smooth as possible.
* Tape two layers of plastic wrap across the opening you cut in the lid—one layer on the top and one layer on the bottom side of the lid.
* Test the stick you will use to prop the lid up. You may have to use tape or figure another way to make the stick stay put.

## Put the oven to work

Set the oven in the direct Sun, with the flap propped to reflect the light into the box. You will probably have to tape the prop in place. Preheat the oven for at least 30 minutes.

## To make S’mores, you will need:

* Graham crackers
* Large marshmallows
* Plain chocolate bars (thin)
* Aluminum pie pan
* Napkins!
Break graham crackers in half to make squares. Place four squares in the pie pan. Place a marshmallow on each. IMPORTANT! Note that unlike most recipes, our s’mores have the marshmallow UNDER the chocolate. That’s because, in the solar oven, it takes the marshmallow longer to melt than the chocolate.
* Place the pan in the preheated solar oven.
* Close the oven lid (the part with the plastic wrap on it) tightly, and prop up the flap to reflect the sunlight into the box.
* Depending on how hot the day is, and how directly the sunlight shines on the oven, the marshmallows will take 30 to 60 minutes to get squishy when you poke them.
* Then, open the oven lid and place a piece of chocolate (about half the size of the graham cracker square) on top of each marshmallow. Place another graham cracker square on top of the chocolate and press down gently to squash the marshmallow.
* Close the lid of the solar oven and let the Sun heat it up for a few minutes more, just to melt the chocolate a bit.
Enjoy!
* ↑ "NASA Climate Kids :: Make Sun S'mores!". climatekids.nasa.gov. Retrieved 2018-06-24.
# Primary learning to read resources

List of free to use resources for teaching early reading, phonics, and sight words.

## Books

* Early phonics readers (books) from Progressive Phonics. Free to download/read.
* Fun phonics readers. Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License
# Primary mathematics/Adding numbers
## Adding two single digit numbers

When teaching young students how to add you will need to use physical items to help them understand how addition works, use items that are similar to avoid confusing younger children. It is very important that they understand the number system before trying to add or subtract. The following is an example of how to show a child how to add.
I have two blocks, Mary has two blocks, if Mary gives me two blocks how many blocks do I have?
First show that you do in fact have two blocks, then show that Mary (or whatever the name of the person is) also has two blocks. Have the children count the number of blocks you have and the number of blocks Mary has.
Have Mary give you two blocks, now have the children count how many blocks you have. You have four blocks and now Mary has zero blocks. Some children may be able to understand addition better if you teach subtraction at the same time, some may notice that Mary has zero blocks while others may not make this connection, this depends completely on each child.
This block example should be done multiple times until every student understands how to add two single digit numbers together, if some students have trouble understanding the concept have them hold the blocks and do the above block example with each other, help them count the blocks they have.
When the basic concept of adding has been introduced via a physical method children should be encouraged to learn the combinations of single digit numbers - so that addition no longer relies on counting blocks (or fingers). Especially important for mental subtraction is to learn the combinations of numbers that add to give 10.
When these basics have been taught and before moving on to adding 2 digit numbers children must learn place notation (ie that 25=20+5). Once this is learnt children can progress to adding 2 (and more) digit numbers. It needs to be explained that when you have 10 in the units column you must 'carry' that over to be 1 in the 10s column. Note that this means that 25+97 is MUCH harder than 12+13.
Depending on the child it can be useful to do this in binary as there are far fewer number combitations to remember, though this can confuse some children.
Due to place notation addition is usually carried out right to left:
With the 1 underneath representing a carried digit.
It is possible to do addition left to right:
(adding the tens first).
Children taught this way will usually work out for themselves the shorter way of writing it out.
# The Varanasi Heritage Dossier/Tripurabhairavi Ghat

Detailed description of each heritage Site - Ranamahal Ghat to Tripurabhairavi Ghat
Varahi and Tripurabhairavi Ghats

### Location

25º 18.497’ North and 83º 00.567’ East (Varahi Devi temple). 25º 18.523’ North and 83º 00.582’ East (Jarasandheshvara, in the wall).

##### Exact location on a map

Varahi and Tripurabhairavi Ghats.

#### Area

0.167 ha

### Historical/cultural/natural significance

In the neighbourhood there is an ancient shrine of (Adi) Varahi (D 16/84) by which the name of ghat called Varahi Ghat. In fact, this ghat is a southern part of Tripurabhairavi. In 1958 the government of Uttar Pradesh has made the ghat pucca and separated it, that is how sometimes this ghat is counted independently. The ghat is distinctly marked by the house of (late) Kailash Nath Chaudhuri, a Domaraja (“king of the funeral priests”), which was donated to him by one of the kings of Banaras. In the neighbourhood scheduled castes (e.g. Harijan, Dom) are more in number. The ghat is relatively more dirty, therefore pilgrims take bath at Tripurabhaitavi before paying visit to Varahai Devi. -- Nearness to the shrine of Tripurabhairavi has given the honour to name the ghat Tribhurabhairavi Ghat. Giravana-padamanjari (17th century) has mentioned it as Vriddhaditya Ghat, after an old disc of Sun god. Later in late 18th century the temple of Tripurabhairavi was built and that replaced the old name. Till 1931 the ghat was only partly built with stone slabs as mentioned by Motichand (1962). Mahananda Giri made the ghat fully pucca in the early 20th century, and also built a monastery (no. D 5/ 100). The repairing and restructuring were done by the government of Uttar Pradesh in 1958. In the upper part under a huge holy fig (pipal) there are many fragments of old images belonging to 12th-13th centuries, e.g. Surya, Ganesha, Vishnu and Shiva lingas. Close to it is a shrine containing images of Hanuman and goddess. The ghat is preferred by the Tamil pilgrims; there is rest house for pilgrims, mostly used by Tamil and Telgu visitors.

### Present state of conservation

Except by the temple trusts directly taking care of its properties, there are no specific action plans, programmes and strategies for conservation and preservation of the ghats. The trusts maintain their properties according to their own perspectives without specific plans.

### Specific measures being taken for conserving the specific property

It is expected that by the support of active people participation, awareness to save the age-old rich heritage, and development under the Master Plan (and its judiciary control) the ghat heritage will be protected and conserved for the better befit to the society.

### Ownership

The temple related properties along the ghat are owned by the temple trusts and monasteries; the houses and other properties by the inhabitants; and the ghat area is owned by the Municipal Corporation.
# The Varanasi Heritage Dossier/Some of the main architectural illegalities on the Ghats in Varanasi Ghat

Some of the main architectural illegalities on the Ghats in Varanasi Ghat
[[|thumb|upright=1.2|left|K 24/28 Ram Ghat That this building is illegal not only because it is built on the Ganga riverfront ghats in Varanasi after the year 2000 but primarily because it is built within 100 metres of an ASI protected monument (Dharhara Mosque), thereby violating the National Monument Act of 1958. Repeated FIRs filed by ASI (12.6.2000; 8.9.2001; 8.9.2003; 1.3.2004; 22.12.2004) against the owners of this illegal construction. Despite VDA issuing demolition orders for this illegal construction on 8 November 2005 and 28 June 2006, the illegal construction continues to exist since 7 years.]]
# Refresher/SDLC/Testing
### Presentation

| Data Structures | Testing | Maintenance | List of Topics | This presentation was made possible by Wikiversal/WikiverSuite, which is made possible by your donation. Thank you for your support. | Maintenance |
* Regression test: testing that looks for regressions after enhancement
* Requirements traceability matrix: completeness of many to many relationship between two baselined documents
* Test Coverage Matrix: Feature, Module, Case Type, Test Case
* Case Type: Default Case, Negative, Boundary
* Integration test: unit test with dependencies between business and data layers
* Unit test: integration test using mocked up business objects and database mockups
* Unit testing framework: toolset essential for testing the code quality
* Integration and configuration errors: types of problems frequently encountered in production
* Code coverage: a measure used in software testing showing the code proportion tested
* Types of code coverage: function, statement, decision, etc.
* Black-box testing: test the functionality of an application
* White-box testing: test internal structures of an application
* Functional testing: a type of black box testing that bases its test cases on the specifications
* Exploratory testing: a black box testing technique, free-lance testing, cognitive engagement of the tester
* Test suite: a collection of test cases showing a specified set of behaviors in the software
* Test case: a set of conditions or variables to be considered in testing
* Test plan: definition of workflow for testers
* Test organization: based on available testing human resources, including developers available for testing
* Web testing: basic functionality, security testing, load testing, performance testing, etc.
* Ecommerce smoke test: at first round-trip testing involving all vendor web services
* Reducing acceptance testing surprises: involve the customer in design of acceptance test
# Refresher/SDLC/Maintenance
### Presentation

| Testing | Maintenance | Configuration Management | List of Topics | This presentation was made possible by Wikiversal/WikiverSuite, which is made possible by your donation. Thank you for your support. | Configuration Management |
* Product update: service interruption should be avoided or announced in advance, backward compatibility, database conversion
* Debug strategy: isolating the code, adding trace logic, and optimizing problem recreation
* Regression tests: making sure other parts, components not broken by the new code
* Sandcastle: a documentation generator from Microsoft via reflection information of .NET assemblies and XML documentation comments found in the source code of these assemblies.
* More easily maintainable: follow best practices and internal standards for coding, logging, commenting, etc. Using OOP plays a major role.
* Debug in production: turn on debug logging, monitor the database in real time
* Load balancing: methodology to distribute workload across multiple devices to achieve optimal resource utilization, maximize throughput, minimize response time, and avoid overload
* Types of Load Balancing: DNS load balancing, Bridged load balancing, and Routed load balancing
* Maintenance most expensive: each change goes through the whole SDLC yet requires all-out regression testing
* Reengineering: examination and alteration of a system to reconstitute it in a new form
* Reverse engineering: discovering the technological principles of a system through analysis of its structure, function, and operation
# Refresher/SDLC/Project Management
### Presentation

| Configuration Management | Project Management | List of Topics | This presentation was made possible by Wikiversal/WikiverSuite, which is made possible by your donation. Thank you for your support. | List of Topics |
* Iron triangle in software development: scope, time and cost
* Scope: features, functionality
* Time: schedule
* Cost: resources, budget
* Estimates: by team members
* Deadline: by the management team
* Agile: iterative and incremental development
* Iterations and Increments: periodic evaluation of new deliverables
* Risk management: the identification, assessment, and prioritization of risks followed by coordinated and economical application of resources to
* minimize, monitor, and control the probability and/or impact of unfortunate events or to maximize the realization of opportunities
* Risk Management Golden Rules: process, identification, communication, opportunities, ownership, prioritization, analysis, response
* preparation, registry, task tracking
* Work breakdown structure (WBS): deliverable-oriented decomposition of a project into smaller components
* Rolling wave planning: progressive elaboration to add detail to the Work Breakdown Structure (WBS) on an ongoing basis
* Burn down chart: graphical representation of work left to do versus time
* Dynamic systems development method (DSDM): generic approach to project management and solution delivery
* PRojects IN Controlled Environments 2 (PRINCE2): a structured project management method endorsed by the UK government as the project management standard for public projects.
* Scrum: an iterative and incremental agile software development method for managing software projects and product or application development
* Customer wants too much: show them alternative outcomes and ask for their help with prioritization
# Refresher/SDLC/Requirements - Part 2
### Presentation

| Requirements | Requirements - Part 2 | Functional Design | List of Topics | This presentation was made possible by Wikiversal/WikiverSuite, which is made possible by your donation. Thank you for your support. | Functional Design |
* How to deal with changing requirements: agile -- Scrum & XP
* Sources for requirements: stakeholders and best practices
* Requirements prioritization techniques: MoSCoW Analysis -- Must, Should, Could and Won't be part of the final solution.
* User responsibilities in requirements process: requirements articulation and validation
* Customer responsibilities in requirements process: requirements gathering and prioritization
* Developer responsibilities in requirements process: requirements analysis and definition
* Incomplete or incomprehensible requirements: ask for clarification, or approval of a revised version
# Refresher/SDLC/Technical Design
### Presentation

| OOP | Technical Design | Construction | List of Topics | This presentation was made possible by Wikiversal/WikiverSuite, which is made possible by your donation. Thank you for your support. | Construction |
* Concurrency control: pessimistic or optimistic locking
* Pessimistic locking: immediate locking upon request
* Optimistic locking: clearing at commit time
* Software design patterns: solution template for many situations
* OO design pattern: relationships and interactions between classes or objects
* Mutable: prone to frequent change
* Immutable: not subject to change
* Types of design patterns: creational, structural, behavioral and concurrency
* Creational design patterns: Lazy initialization, Multiton, Singleton, etc.
* Structural design patterns: Adapter, Composite, Decorator, etc.
* Behavioral design patterns: Chain of responsibility, Iterator, Memento, etc.
* Concurrency design patterns: Lock, Scheduler, Thread pool, etc.
* Iterator design patterns: Collections -- List<string>
* Stateless protocol: each request a transaction independent of previous requests
* Stateless object: no attributes, only methods, lower invocation overhead
* Multi-tier architecture: presentation, application processing, and data management are separate processes
* Business Logic Layer (BLL): business process objects and business entities
* Stateless business layer: minimal overhead for long-running transactions
* Entity Data Model (EDM) diagrams: scalar properties, navigation properties, etc.
* Sequence diagram: interaction diagram showing how processes operate with one another and in what order
* ArchiMate: an open and independent enterprise architecture modeling language
* Component-based design (CBD): a reuse approach to defining, implementing and composing loosely coupled independent components into systems
* Software component: a software package, a Web service, or a module that encapsulates a set of related functions
* Service-orientation: a design paradigm to build computer software in the form of services
* Service-oriented architecture: a set of principles and methodologies for designing and developing software in the form of interoperable services
* SOA principles: reuse, granularity, modularity, composability, componentization and interoperability
* CBD or SOA: application of OOP at a higher level, e.g. to encapsulate a service as provided by an independent vendor
# Refresher/SDLC/Topic List
### Presentation

| Introduction | Topic List | Basic Concepts | This presentation was made possible by Wikiversal/WikiverSuite, which is made possible by your donation. Thank you for your support. | Basic Concepts |
* Basic Concepts
* FAQ
* References
* Requirements
* Requirements - Part 2
* Functional Design
* OOP
* Technical Design
* Construction
* Abstract and Interface
* Delegate and Polymorphism
* Construction - Part 4
* Algorithms
* Data Structures
* Testing
* Maintenance
* Configuration Management
* Project Management
# Refresher/SDLC/OOP
### Presentation

| Functional Design | OOP | Technical Design | List of Topics | This presentation was made possible by Wikiversal/WikiverSuite, which is made possible by your donation. Thank you for your support. | Technical Design |
* Programming paradigm (fundamental style): OOP, imperative (emphasizing state changes) and functional (emphasizing use of functions)
* Functional programming example: int sum = Enumerable.Range(1, 9).Where(i => i % 2 == 0).Sum;
* Imperative programming example: for (int i = 1; i < 10; i++) if (i % 2 == 0) sum += i;
* OOP: using objects in programming with object data fields, methods and their interaction
* OOP features: data abstraction, encapsulation, message passing, modularity, polymorphism, and inheritance
* Abstraction: what to expose, what to hide
* Data abstraction: factoring out details
* Information hiding: the principle of segregation of the design decisions
* Information hiding example: Weights.Compare(Weight argWeight1, Weight argWeight1)
* Encapsulation: enclosing in a capsule or object, a technique in information hiding
* Encapsulation example: Box box1 = new Box; if (box1.Heavier(box2)) { }
* Messaging passing: objects or processes can wait for messages from others
* Process synchronization: multiple processes agreeing to a sequence of action
* Modularity: separation of concerns (features and behaviors)
* Coupling: degree of interdependencies between modules or classes
* Cohesion: how much functions or methods within a module are related to another
* Low coupling: classes should loosely dependent like lego pieces
* High cohesion: methods highly related like jigsaw puzzle pieces
* Low coupling and high cohesion: classes like lego, methods like jigsaw puzzle
* Polymorphism: objects from different types responding to calls by the same name, e.g. operator overloading for addition
* Inheritance: code reuse by establishing a subtype from an existing object
* Inheritance example: class Employee extends Resident extends Person
* Method overriding: providing a method with same name, signature, and return type as that of the parent class
* Keyword 'internal' in C#: Friend in C++ is not your friend
# Refresher/SDLC/References
### Presentation

| FAQ | References | Requirements | List of Topics | This presentation was made possible by Wikiversal/WikiverSuite, which is made possible by your donation. Thank you for your support. | Requirements |
* The material herein are based on the 100 questions posed on this page: http://www.noop.nl/2009/01/100-interview-questions-for-software-developers.html