OpenLLM-France/wikimedia huggingface dataset:
# Software Engineers Handbook/Life Cycle/Design/Choosing an Algorithm
## Finding an Algorithm

In many cases, the issue is finding or creating any algorithm. Here are some hints to get past the algorithm writers block, to find an existing algorithm you didn't know existed, and new ways to find algorithms you already knew existed.

### Phone a friend.

    Thoroughly explaining the problem you need to solve to someone else in person, on the phone, or in email often allows you to generate a solution. Your friend might have a solution as well.

### Read an algorithm textbook.

    Skimming or reading an algorithm textbook can produce more terms for web searches, and fields likely to use this algorithm. You might just stumble on the answer.

### Search in other fields.

    If you can express your problem as a problem in other fields, such as computer graphics, other resources become viable.

### Try a newsgroup.

    There's a really good chance that someone else has experienced this problem before. Open source solutions may already be available.

## Choosing an Algorithm

In the case where you find more than one appropriate algorithm, you can use these ideas to compare their suitability for your application.

### Implement, then optimize.

    All algorithms available may be good enough.

### Performance

    How does it run on your typical data? How does it run on your exceptional data?

### Ease of Implementation

    How quickly can you get this algorithm implemented and running?

### Scalability

    What is the order (big O notation) of the algorithm? How does it scale with more input? How does it scale with more complex input?

### Maintainability

    How easy is the algorithm to understand and maintain?

### Multi-processor compatibility

    Do you have multiple processors available? Does this algorithm maximize their usage?

### Size

    Is code size an issue? Is memory/cache/file size and issue?
These questions will be weighted differently for different applications. For instance, a prototype will likely emphasize the ease of implementation over the other criteria. A search through a massive database is likely to emphasize performance over the other criteria.

## Books and Articles

* Introduction to Algorithms ISBN 0262032937 by Thomas H. Cormen, Charles E. Leiserson, Ronald L. Rivest, and Clifford Stein is a classic Algorithms textbook.

## Links

* Selecting the Right Algorithm by Lagoudakis et al. discusses choosing the correct sorting algorithm
* Selecting a Hashing Algorithm by McKensie et al.
* comp.graphics.algorithms FAQ contains links and discussions on many algorithms
# Software Engineers Handbook/Life Cycle/Design/Patterns

A software design pattern is a general reusable solution to a problem that repeats itself in software design within a given context. It is not a finished design that can be transformed directly into code, and constitutes a description or template for a problem that can be used in many different situations. Software design patterns are formalized best practices that have to be implemented in applications. A part of the software design patterns are object-oriented design patterns that show relationships and interactions between classes or objects without specifying the final application objects that are involved. Patterns that imply object-orientation or more generally mutable state, are not as applicable in functional programming languages.
Software design patterns reside in the domain of modules and interconnections. At a higher level there are architectural patterns that are larger in scope. These usually describe an overall pattern followed by an entire system.
Important design pattern types are
* Behavioural patterns
* Concurrency patterns
* Creational patterns
* Structural patterns

## See also

* Design Patterns in Software Engineering

## References

* ↑ 1. Introduction to Spring Framework
* ↑ Martin, Robert C. "Design Principles and Design Patterns" (PDF). Retrieved 2000. {{cite web}}: Check date values in: |accessdate= (help)
# Software Engineers Handbook/Language Dictionary/Visual J++
## Visual J++

Here is the Java wikipedia entry.

### Type

Visual J++ is a full, procedural, object-oriented, visual language.

### General Syntax

The typical statement is completed by a semi-colon. For the assignment of b to a use:

### Comments

Block comments are specified by a starting /* and ending */ They can span multiple lines.

### Scope

Scope is defined by curly braces.

### Conditional Statements

If and only if A is equal to B assign C to D, otherwise, assign E to F.
or
Alternatively, a switch statement can be used for multiple choice operations. This sample converts a number input to text.

### Looping Statements

This code counts from 0 to 9, adding up the contents of the array.
This code repeats until the number 4 is found. If this runs off of the end of the array, there could be a problem.
This code increments the counter before the check is made, so that it starts with element 1.

### Output Statements

And adding text to visual components.

### Containers

Containers inherit from the Collection class. See the java.util package for specific containers including Vector.

### Algorithms

What algorithms does it have? Does sort work in J++?

### Garbage collection

Garbage collection is automatic.

### Physical Structure

Code is generally kept in files with a .java extension. It is compiled into Java byte code into files with .class extensions.

### Tips

* The language is very similar to Java.
* Visual form layout and component access is similar to other Microsoft Visual development languages.
* Classes in the Java packages are capitalized, methods are not.
* Everything is a pointer. Use a clone method to avoid operating on the original element of a Collection.
* Arrays start with index 0.
* Don't confuse these two:
Often using the one you don't want will compile, and will produce results you did not expect.

### Web References

* Java wikibooks page
* Microsoft support is available at the [Microsoft Developers Network] pages.

### Books and Articles

paper references here
# Software Engineers Handbook/Life Cycle/Development Methodologies/Traditional Waterfall

When it was first created, the Waterfall Model of Software Development presumed that writing software is a linear process, with clearly defined phases. Many experts have come to realize that this is not true in all cases. However, Waterfall is always useful as a checklist, even if it is not followed in a linear, rigorous fashion. A summary follows.
Phases:
* Requirements Allocation
* Preliminary Design (AKA Top Level Design or Architecture)
* Detailed design
* Code and Unit Test
* Integration and Integration test
Scope:
* Requirements
** Capabilities – what the software does
** Human interface – all screens and messages defined
** All interfaces to external hardware and software identified
** Size and timing requirements
* Preliminary Design
** Structure diagram
** Functional flow diagrams
** All major function prototypes defined and comments for functions written
** All major data structures and data bases defined
** Header files defined
** Sizing and timing estimates (may be deferred to detailed design)
* Detailed Design
** PDL C Program design language (or pseudo code) written. Rule of thumb: 1 line of pseudo code = 3 to 10 lines of “C” code (approximately).
** Better sizing and timing estimates
* Code And Unit Test
** Convert PDL to code
** Design unit test plan and test code. Test Drivers, test stubs, and any special requirements defined (e.g., special test hardware configurations, test software, lab equipment, etc.).
** Better sizing and timing estimates
** Metrics, test coverage tool results, etc.
* Integration and Integration Test
** Design integration test plan and test code
** Run code on target system and debug
** Take sizing and timing measurements and ensure that you are meeting requirements.
** Line count - Total lines of text, and lines of code.
# Software Engineers Handbook/Life Cycle/Software Requirements Specification
## Links

* Guide to writing effective requirement specifications
* Soda-pop machine example SRS using Swedish currency
* IEEE Recommended Practice for Software Requirements Specifications IEEE Std 830-1998
# Software Engineers Handbook/Life Cycle/Development Methodologies
## Iterative Development Method

the Wikipedia entry

### References
## Waterfall Development Method

the Wikipedia entry

### References
## Agile Development Method

the Wikipedia entry
# WebObjects/Web Applications/Development/Calling Commandline Applications

Here, the "cat" and "outputCat" are debugging output categories:
Note: A number of people have reported problems with process.waitFor on Windows. The WebObjects Development List at Omnigroup has a number of people's workaround code for this problem.
Note 2: The procedure given here, of course, is to call anything executable from the command line from your Java program, not just Perl scripts.

#### Mike Schrag

process.waitFor is not just a problem on Windows. This code will cause problems. Process maintains buffers for stdout and stderr. If you do not consume those streams, you will run into deadlocks. The proper way to use Runtime.exec is to setup a thread for stderr and a thread for stdout and consume them yourself into your own buffer that does not have the same restrictions that the stock VM has.
There's a good example of this technique on JavaWorld.
# WebObjects/Web Applications/Development/Common Pitfalls and Troubleshooting
### Debugging Classpath Problems
#### Chuck Hill

I recently found this useful and thought others might too:
Add this to public static void main(String argv) before the call to WOApplication.main(argv, Application.class) and add these imports:
# WebObjects/Web Applications/Development/Component Actions
### Overview

The Component Action Request Model is the default means for handling user requests in WebObjects. It is based on the idea of interactive page objects (components).
A page creates some HTML and paints the screen for the user. The component object is stored as part of the user's session, with all of its state. When the user clicks a link or submits a form on the page, the URL has been constructed in such a way that the server can determine which component object was used to create the page originally, and re-uses this object to handle the request.
Thus, you can do quite a good job of forgetting you are on the web, and that the only information the user supplies with each request is the URL, form submission, cookies etc. You can create interactive pages which deal with many requests, simply changing their internal state in response to each one, as though you were writing a non-web application to be used locally.
I'm not familiar myself with JSP, but I'm told by people who are that this makes highly dynamic database editing pages (for example editing several linked tables at once) much easier in WebObjects than JSP. I can confirm this is indeed trivial in WebObjects, although I don't know myself why it is harder in the JSP model.
Note that the Component Action Request Model has some disadvantages. Each URL, to be handled, must find the matching component object in memory. Thus, once the session has timed out, the URL becomes largely incomprehensible and good handling of this situation is difficult. One option is to add additional values as a query string on the URL - this will not break standard request processing but could be used to provide the correct information to recover if the session is gone. Additionally, sessions cannot remember infinite component objects, unless you want to throw memory at the problem, so by default only 30 are stored. This means it is possible for users to backtrack too far and create problems, especially if you are using multiple frames or windows.
For cases where highly interactive pages are not required, you may prefer Direct Actions, which has none of these disadvantages, but provides less help.
# WebObjects/Web Applications/Development/Custom Resource Manager
## Petite Abeille

Here is a little example on how to write your own WOResourceManager:
The main methods to implement are urlForResourceNamed and bytesForResourceNamed.
* urlForResourceNamed simply build an URL for a resource from wherever you would like (e.g. a jar file). Unfortunately, urlForResourceNamed uses pathForResourceNamed so you will need to rewrite that also:
* bytesForResourceNamed simply retrieve a resource from wherever you would like (e.g. a jar file):
* Last but not least, you need to take care of those funky WOURLValuedElementData so dataForResourceNamed will work:
* Finally, you need to register your resource manager with WOApplication:
Handling of languages and frameworks are left as an exercise to the reader.
# WebObjects/Web Applications/Development/Custom Templates
### Petite Abeille

[The following solution is more involved than what is strictly needed. It may avoid the debug message, he is using some quasi-private stuff.

#### It can be quite easy

A More Involved Solution:
Here is a little example on how to overwrite WOComponent.template so you can load the html template and wod from wherever you want )eg a jar file):
* First you will need to overwrite WOComponent.template
* Now, templateForComponent could look like this:
* The componentTemplateWithExtension method could look like the following:
* And finally componentStreamForResource could be something along these
lines:
# WebObjects/Web Applications/Development/Backtracking
### Backtracking

When Component Actions are used with WebObjects, to be able to preserve state across requests, the server must maintain a cache of previously visited pages. This page cache has a limited size. As a result, if the user presses the back button too many times to the point of exhausting this cache, it will result in a "User has backtracked too far" error.

### Prevention with Direct Actions

Because direct actions don't require page state like component actions, the best way to avoid backtracking problems is to use Programming:WebObjects/Web Applications/Development/Direct Actions in your app.

### Old Sessions and Backtracking

What is the simplest way to prevent a user from backtracking (using the browser back button) to the pages previously used by another user who has logged out?
To keep users from accessing someone else's session when they use the back buttion, you should call the session.terminate in your logout action. In order for this to work, you have to issue a redirect, after calling terminate, to page with no session, because if you return another page using pageWithName, that page will reference the session you just terminated, and it won't work. My logout action looks something like this:
This will prevent the session from working if someone uses the back button, but it doesn't prevent them from seeing the content on the pages. If sensitive content is the issue, the best thing to do is to close the window when the user logs out. This would assume that when they logged in, you opened a window for the sensitive part of the app to run in. That way, when you use javascript to close it, you won't trigger a warning message that the user can intercept. With a window that you opened, you can do the redirect like above, to an html page that looks like:
Then there won't be any pages to go back to.
# WebObjects/Web Applications/Development/CSS
### Overview

CSS stands for Cascading Style Sheets. It's provides a mechanism to separate the presentation of your HTML page from the logical structure and content of your HTML page.

### Referencing a Style Sheet
#### Style Block

The easiest way to include CSS in your WebObject application is put a style block in your <head> tag:

#### Static Reference

Another easy way to use CSS in your WebObjects application is to include a static reference to it with:
However, if you're a WO developer, you know static resource references feel dirty. Don't worry, there are alternatives.

#### Project WOnder

Project WOnder provides ERXStyleSheet, which is a stateless component with a template that can generate link tags for you.

#### Mike Schrag's MDTStyleSheet

The following dynamic element can be used to include a stylesheet in your page. It supports the bindings "rel", "type", "href", "src", etc similar to a WOImage.

### Stylesheet Component

Here is a trivial example on how to define style sheets properties at runtime:
Simply create a component with your style sheets properties:
And use some wod for the parameters:

### Related Links

* CSS Programming
* CSS on Wikipedia
* W3 Schools on CSS
# WebObjects/Web Applications/Development/Custom Error Handling
### Exception Page

To provide a custom error handler when an exception is thrown, override the method:
For example:

### Session Expired

To provide a custom error handler when an exception is thrown, override the method:
For example:

### Your Request Produced an Error
#### Chuck Hill

This message started to appear in WO 5.2 when an exception was raised in a DirectAction, but only in deployed applications. Here is what is happening:
WODisplayExceptionPages true or false to enable or disable the generation of WOExceptionPages for direct action requests. Default is true in development mode and false in deployment mode.
From http://developer.apple.com/documentation/WebObjects/WOAppProperties/AppProperties/chapter_1_section_1.html
If the page being returned throws during appendToResponse and the app is deployed, all that is displayed is a blank page with the words "Your request produced an error".
To avoid this, either add this to the launch agruments:
Or change the main method in your Application class to look like this:
This won't work if you put it in the constructor.
# X86 Disassembly/Cover

The Wikibook of
Using C and Assembly Language
From Wikibooks: The Free Library
# X86 Disassembly/Disassembly Examples
## Example: Hello World Listing

Write a simple "Hello World" program using C or C++ and your favorite compiler. Generate a listing file from the compiler. Does the code look the way you expect it to? Do you understand what the assembly code means?
Here are examples of C and C++ "Hello World!" programs.

## Example: Basic Disassembly

Write a basic "Hello World!" program (see the example above). Compile the program into an executable with your favorite compiler, then disassemble it. How big is the disassembled code file? How does it compare to the code from the listing file you generated? Can you explain why the file is this size?
# Solitaire card games/Tabby Cat

Tabby Cat was created by Rick Holzegrafe, and is a single-deck solitaire card game reminiscent of Miss Milligan.

## Rules

The play consists of four stacks in the tableau, with an additional "tail", where builds can be placed. Four foundations are available, and the goal of the game is to build up kings to aces (low), regardless of color or suit, whereupon the build can then be cleared from the tableau and moved to a foundation.
The play proceeds by sequentially dealing four cards to each stack of the tableau. These stacks are to be managed, building cards of lower rank on top of cards of higher rank. Building is circular, allowing a King to be built onto an Ace. Only the topmost build (or portion) may be moved from a tableau stack. An empty stack can receive any movable card or build. Partial or full builds can be moved onto the tail only if the tail is empty. If the build has, for example, 9 as its highest rank, to move off the tail it must be moved onto a card of rank 10 or onto an empty tableau space.

## Variant

Closely related to Tabby Cat is another of Rick's solitaire games entitled Manx. The two games are identical except for the rules about the tail, with Manx being the more difficult of the two.
Both Tabby Cat and Manx have been implemented in numerous solitaire software packages, including Rick Holzegrafe's own Solitaire Till Dawn program.

## References

* ↑ Tabby Cat
# Solitaire card games/Six By Six

Layout: The game consists of 6 columns each with 6 cards dealt to them at the start of the game. If any aces are found during the deal then they are moved to the foundations and the next card dealt replaces it. Play: Build in descending sequence on the tableau. A block of same suit cards can be moved at once. A space can be filled by any card. Cards are dealt from the stock to the first tableau column. There is no redeal.
# Solitaire card games/Thirteen

Thirteen can be an alternative name for these solitaire games:
* Baker's Dozen,
* Baroness,
* Canfield
# Solitaire card games/Spiderette

This is a challenging combination of Klondike and the two-pack Spider.
Thee first 28 cards are dealt the same way as in Klondike, i.e. the first column should have one face-up card, the second column should have one face-up card and one face down card at the bottom, and so on.
Cards in the tableau are built down regardless of suit. Only the top cards of each column can be moved; however, a sequence of cards that are in suit (such as 9-8-7-6♥) can be moved as one unit. Face-down cards that become exposed are turned face-up and empty column spaces on the tableau are filled by any card. If all possible plays have been made, a new set of seven cards (one for each column) are dealt, provided that each column must contain at least one card. After three such deals, and the game becomes stuck, the three left over cards are dealt on the first three columns.
Once a suit sequence of 13 cards from king down to ace is successfully built, it is discarded from the game. The game is won when four such suit sequences were built and discarded this way.

## Variations

Will o' the Wisp – On the onset, twenty-one cards are dealt into seven columns of three with only the top card of each column face-up.
# Solitaire card games/The Clock
## Play

Imagine a clock on your game table. All ones will be placed at the 1 o'clock position, all Queens on 12 o'clock, and the kings in the center. This game has no cascades. In the figure the stock and waste are inside the clock. If playing the game with a real deck you would hold the stock in your hand and put the waste at a convenient location outside the clock.
* Draw card by card from the stock. If one fits to any of the 13 foundations play it, otherwise put it on the waste.
* Foundations are built by alternating color and layer wise, this means that you can choose your starting suit, but the second card on the foundation must be opposite color.
* Layer wise by suit means that you must have the same suit on each layer of the foundations. So on all foundations you must have - for example - Spades, Diamonds, Clubs, Hearts in the same order, though you can choose the order during the first moves of the game. The game allows you to recycle the waste stack exactly two times.
# Solitaire card games/Yukon

Similar to Klondike, but with the following additions:
* Groups of cards can be moved; the cards below the one to be moved do not need to be in any order, except that the starting and target cards must be built in sequence and in alternate color. For example, a group starting with a Red 3 can be moved on top a Black 4, and the cards below the Red 3 can differ.
* There is no stock in Yukon. All cards are dealt at the beginning; however, some are face down.

## Variations

* Russian Solitaire is another solitaire card game which is very similar in layout and gameplay to Yukon. Its difference from Yukon is that building is by suit.

## Strategy

* Expose the face down cards as soon as possible, so you can start moving cards around.
* Moving the Aces to the Foundations as soon as possible is critical to gameplay.
# Solresol/Orthography

Solresol, being based on 7 syllables, has a wide variety of ways to be written. The most popular are:
* The musical tones are written out in full (do, re, mi, fa, sol, la, si)
* The musical tones are abbreviated (d, r, m, f, so, l, s)
* The musical tones are written as numbers (1, 2, 3, 4, 5, 6, 7)
* The musical tones are written on a musical staff (do=c, re=d, mi=e, fa=f, sol=g, la=a, si=b)
* The musical tones are written as colors (Do=red, re=orange, mi=yellow, fa=green, sol=blue, la= indigo, si= violet)
* The musical tones are written in a stenographic script.
Out of these, the full written out form, the abbreviated, and the number forms are the most widely used.