# HG changeset patch # User Oleksandr Gavenko # Date 1276625701 -10800 # Node ID 90e66cb8292abe4ee51f670b86452304a6711a2f # Parent 95d5fafa0a88763c34708dea8686d63d2ed5e587# Parent 645990ee83c80e55ee2bee5132345854d193888a merged diff -r 95d5fafa0a88 -r 90e66cb8292a bnf.rst --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/bnf.rst Tue Jun 15 21:15:01 2010 +0300 @@ -0,0 +1,40 @@ +-*- mode: outline; coding: utf-8 -*- + +* What is BNF? + +BNF is an acronym for "Backus Naur Form". John Backus and Peter Naur +introduced for the first time a formal notation to describe the syntax of a +given language (ALGOL 60 programming language). + + rfc2234 + +* BNF syntax. + +The meta-symbols of BNF are: + + ::= + meaning "is defined as" + | + meaning "or" + < > + angle brackets used to surround category names (some times skipped). + [ ] + optional items are enclosed in. + { } + repetitive items (zero or more times) are enclosed in. + " " + terminals are enclosed in to distinguish them from meta-symbols. + +* BNF in BNF. + + syntax ::= { rule } + rule ::= identifier "::=" expression + expression ::= term { "|" term } + term ::= factor { factor } + factor ::= identifier | + quoted_symbol | + "(" expression ")" | + "[" expression "]" | + "{" expression "}" + identifier ::= letter { letter | digit } + quoted_symbol ::= """ { any_character } """ diff -r 95d5fafa0a88 -r 90e66cb8292a devel-rules.rst --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/devel-rules.rst Tue Jun 15 21:15:01 2010 +0300 @@ -0,0 +1,664 @@ +-*- mode: outline; coding: utf-8 -*- + +* General discussion. + +See + + http://en.wikipedia.org/wiki/List_of_software_development_philosophies + http://en.wikipedia.org/wiki/List_of_eponymous_laws + +* Principle of good enough (POGE). + +It favours quick-and-simple (but potentially extensible) designs over +elaborate systems designed by committees. + +Once the quick-and-simple design is deployed, it can then evolve as needed, +driven by user requirements. + +This kind of design is not appropriate in systems where it is not possible to +evolve the system over time, or where the full functionality is required from +the start. + +See + + http://en.wikipedia.org/wiki/Principle_of_good_enough + +* No Silver Bullet. + +There is no single development, in either technology or management technique, +which by itself promises even one order of magnitude improvement within a +decade in productivity, in reliability, in simplicity. + +See + + http://en.wikipedia.org/wiki/No_Silver_Bullet + +* Rule of thumb. + +A rule of thumb is a principle that postulate in some case use simple +procedure wich produce approximate result instead use complex but exact +produce. + +See + + http://en.wikipedia.org/wiki/Rule_of_thumb + +* The Zero One or Infinity. + +The Zero One or Infinity (ZOI) rule is a rule of thumb in software design. It +suggests that arbitrary limits on the number of instances of a particular +entity should not be allowed. Specifically, that an entity should either be +forbidden entirely, one should be allowed, or any number (presumably, to the +limit of available storage) of them should be allowed. It should not be the +software that puts a hard limit on the number of instances of the entity. + + http://en.wikipedia.org/wiki/Zero_One_Infinity + +* 80-20 rule (pareto principle). + +This rule postulate that roughly 80% of the effects come from 20% of the +causes. + +This rule applied to optimisation (most time spent by program only by little +piece of code), functionality (80% of users use only 20% of program +functionality); bugs (fixing the top 20% of most reported bugs solve 80% of +the error and crashes). + +See + + http://en.wikipedia.org/wiki/80:20_rule + +* 1% rule. + +The 1% rule states that the number of people who create content on the +internet represents approximately 1% (or less) of the people actually viewing +that content. + +See + + http://en.wikipedia.org/wiki/1%25_rule_%28Internet_culture%29 + +* Parkinson's Law. + +Work expands so as to fill the time available for its completion. + +Data expands to fill the space available for storage. + +See + + http://en.wikipedia.org/wiki/Parkinson%27s_law + +* Ninety-ninety rule. + +The first 90% of the code accounts for the first 10% of the development time. +The remaining 10% of the code accounts for the other 90% of the development +time. + +See + + http://en.wikipedia.org/wiki/Ninety-ninety_rule + +* Wirth's law. + +Software is getting slower more rapidly than hardware becomes faster. + +See + + http://en.wikipedia.org/wiki/Wirth%27s_law + +* Student syndrome. + +Student syndrome refers to the phenomenon that many people will start to fully +apply themselves to a task just at the last possible moment before a deadline. + +The student syndrome is a form of procrastination (). + +See + + http://en.wikipedia.org/wiki/Student_syndrome + +* Conway's Law. + +...organizations which design systems ... are constrained to produce designs +which are copies of the communication structures of these organizations. + +Example: Consider a two-person team of software engineers, A and B. Say A +designs and codes a software class X. Later, the team discovers that class X +needs some new features. If A adds the features, A is likely to simply expand +X to include the new features. If B adds the new features, B may be afraid of +breaking X, and so instead will create a new derived class X2 that inherits +X's features, and puts the new features in X2. So the final design is a +reflection of who implemented the functionality. + +A real life example: NASA's Mars Climate Orbiter crashed because one team used +United States customary units (e.g., inches, feet and pounds) while the other +used metric units for a key spacecraft operation. + +See + + http://en.wikipedia.org/wiki/Conway%27s_Law + +* Brooks's law. + +It takes some time for the people added to a project to become productive. + +Communication overheads increase as the number of people increases. + +Adding manpower to a late software project makes it later. + +See + + http://en.wikipedia.org/wiki/Brooks%27_law + +* Code bloat. + +Code bloat is the production of code that is perceived as unnecessarily long, +slow, or otherwise wasteful of resources. Code bloat generally refers to +source code size but sometimes is used to refer to the generated code size or +even the binary file size. + + http://en.wikipedia.org/wiki/Code_bloat + +* Beerware. + +Beerware is term for software released under a very relaxed license. It +provides the end user with the right to use a particular program. + +Should the user of the product meet the author and consider the software +useful, he is encouraged to buy the author a beer 'in return' (or, in some +variations, drink a beer in the author's honor). + +/* ---------------------------------------------------------------------------- + * "THE BEER-WARE LICENSE" (Revision 42): + * wrote this file. As long as you retain this notice you + * can do whatever you want with this stuff. If we meet some day, and you think + * this stuff is worth it, you can buy me a beer in return Poul-Henning Kamp + * ---------------------------------------------------------------------------- + */ + + http://en.wikipedia.org/wiki/Beerware + +* Demoware. + +Demoware (also known as trialware) is commercial software released for free +(shareware) in a version which is limited in one or more ways. + + http://en.wikipedia.org/wiki/Demoware + +* Crippleware. + +Crippleware is any product whose functions have been limited (or "crippled") +with the sole purpose of encouraging or requiring the user to pay for those +functions (either by paying a one-time fee or an on-going subscription fee). +Crippleware is also a term used to describe software that makes use of Digital +Rights Management. + + http://en.wikipedia.org/wiki/Crippleware + +* Nagware. + +Nagware (also known as begware, annoyware or a nagscreen) is a type of +shareware that reminds (or nags) the user to register it by paying a fee. It +usually does this by popping up a message when the user starts the program, or +intermittently while the user is using the application. These messages can +appear as windows obscuring part of the screen or message boxes that can +quickly be closed. Some nagware keeps the message up for a certain time +period, forcing the user to wait to continue to use the program. + + http://en.wikipedia.org/wiki/Nagware + +* Registerware. + +Registerware refers to computer software which requires the user to give +personal information, e.g an email address, through registration in order to +download or use the program. + + http://en.wikipedia.org/wiki/Registerware + +* Scareware. + +Scareware comprises several classes of scam software, often with limited or no +benefit, sold to consumers via certain unethical marketing practices. + + http://en.wikipedia.org/wiki/Scareware + +* Donationware. + +Donationware is a licensing model that supplies fully operational software to +the user and pleads for an optional donation be paid to the programmer or a +third-party beneficiary (usually a non-profit). The amount of the donation may +also be stipulated by the author, or it may be left to the discretion of the +user, based on individual perceptions of the software's value. Since +donationware comes fully operational (i.e. not crippleware) and payment is +optional, it is a type of freeware. + + http://en.wikipedia.org/wiki/Donationware + +* Freeware. + +Freeware is computer software that is available for use at no cost or for an +optional fee. + + http://en.wikipedia.org/wiki/Freeware + +* Shareware. + +Shareware is proprietary software that is provided to users without payment on +a trial basis and is often limited by any combination of functionality, +availability or convenience. Shareware is often offered as a download from an +Internet website or as a compact disc included with a magazine. + +The rationale behind shareware is to give buyers the opportunity to use the +program and judge its usefulness before purchasing a license for the full +version of the software. + +The words "free trial" or "trial version" are indicative of shareware. + + http://en.wikipedia.org/wiki/Shareware + +* Software bloat. + +Software bloat is a term used to describe the tendency of newer computer +programs to have a larger installation footprint, or have many unnecessary +features that are not used by end users, or just generally use more system +resources than necessary, while offering little or no benefit to its users. + + +Comparison of Microsoft Windows minimum hardware requirements (for 32-bit +versions): + +Windows version Processor Memory Hard disk +Windows 95[4] 25 MHz 4 MB ~50 MB +Windows 98[5] 66 MHz 16 MB ~200 MB +Windows 2000[6] 133 MHz 32 MB 650 MB +Windows XP[7] 233 MHz 64 MB 1.5 GB +Windows Vista[8] 800 MHz 512 MB 15 GB +Windows 7[9] 1 GHz 1 GB 16 GB + +Every program attempts to expand until it can read mail. Those programs which +cannot so expand are replaced by ones which can. + -- Jamie Zawinski + +** Foistware. + +Foistware, Bloatware, or Bundler is software bundled with completely unrelated +programs. That means that there is no particular property in the software that +makes it foistware, but rather the context in which it was installed. + + http://en.wikipedia.org/wiki/Foistware + +** Bloatware. + +Software bloat is a term used to describe the tendency of newer computer +programs to have a larger installation footprint, or have many unnecessary +features that are not used by end users, or just generally use more system +resources than necessary, while offering little or no benefit to its users. +Bloatware, or foistware, is also used to describe software that comes +pre-installed on a computer when it's bought, mostly consisting of +time-limited trials or feature-lacking basic or "beginner" versions. + + http://en.wikipedia.org/wiki/Bloatware + +** Shovelware. + +Shovelware is sometimes used to denote foistware which was chosen to fill up +the remaining space on a freely distributed CD-ROM. + + http://en.wikipedia.org/wiki/Shovelware + +* Second-system effect. + +In computing, the second-system effect or sometimes the second-system syndrome +refers to the tendency, when following on from a relatively small, elegant, +and successful system, to design the successor as an elephantine, +feature-laden monstrosity. The term was first used by Fred Brooks in his +classic The Mythical Man-Month.[1] It described the jump from a set of simple +operating systems on the IBM 700/7000 series to OS/360 on the 360 series. + +* Inner-platform effect. + +The inner-platform effect is the tendency of software architects to create a +system so customizable as to become a replica, and often a poor replica, of +the software development platform they are using. + +XXX read more http://thedailywtf.com/Articles/The_Inner-Platform_Effect.aspx + + http://en.wikipedia.org/wiki/Inner-platform_effect + +* Feature creep. + +Feature creep is the proliferation of features in a product such as computer +software. Extra features go beyond the basic function of the product and so +can result in baroque over-complication, or "featuritis", rather than simple, +elegant design. + + http://en.wikipedia.org/wiki/Feature_creep + +* Bullet-point engineering. + +Bullet-point engineering is a software design anti-pattern where developers +use the features of competing software packages as checklists of features to +implement in their own product. These features are often implemented poorly +and haphazardly, without any real design, merely so they can be added to a +bulleted list of features in marketing material. Bullet point engineering +often leads to feature creep and software bloat but may also simply result in +a poorly designed imitative product. + + http://en.wikipedia.org/wiki/Bullet-point_engineering + +* KISS + +Keep it simple and stupid, or keep it simple, stupid! + +Instruction creep and function creep, two instances of creeping featuritis, +are examples of failure to follow the KISS principle in software development. + + http://en.wikipedia.org/wiki/KISS_principle + +* Minimalism. + +In computing, minimalism refers to the application of minimalist philosophies +and principles in hardware and software design and usage. + + http://en.wikipedia.org/wiki/Minimalism_%28computing%29 + +* Unix philosophy. + +** From Doug McIlroy. + +"Do one thing and do it well." + +"Write programs that do one thing and do it well. Write programs to work +together. Write programs to handle text streams, because that is a universal +interface." + +** From Pike: Notes on Programming in C. + + 1. You cannot tell where a program is going to spend its time. Bottlenecks +occur in surprising places, so do not try to second guess and put in a speed +hack until you've proven that's where the bottleneck is. + 2. Measure. Do not tune for speed until your performance analysis tool tells +you which part of the code overwhelms the rest. + 3. Fancy algorithms tend to run more slowly on small data sets than simple +algorithms. They tend to have a large constant factor in O(n) analysis, and n +is usually small. So don't get fancy unless Rule 2 indicates that n is big +enough. + 4. Simplify your algorithms and data structures wherever it makes sense +because fancy algorithms are more difficult to implement without defects. The +data structures in most programs can be built from array lists, linked lists, +hash tables, and binary trees. + 5. Data dominates. If you have chosen the right data structures and organized +things well, the algorithms will almost always be self-evident. Data +structures, not algorithms, are central to programming. + +** From Mike Gancarz: The UNIX Philosophy. + + 1. Small is beautiful. + 2. Make each program do one thing well. + 3. Build a prototype as soon as possible. + 4. Choose portability over efficiency. + 5. Store data in flat text files. + 6. Use software leverage to your advantage. + 7. Use shell scripts to increase leverage and portability. + 8. Avoid captive user interfaces. + 9. Make every program a filter. + +With this not all agree: + + 1. Allow the user to tailor the environment. + 2. Make operating system kernels small and lightweight. + 3. Use lowercase and keep it short. + 4. Save trees. + 5. Silence is golden. + 6. Think parallel. + 7. The sum of the parts is greater than the whole. + 8. Look for the 90-percent solution. + 9. Worse is better. + 10. Think hierarchically. + +** Misc. + +"Unix is simple. It just takes a genius to understand its simplicity." + -– Dennis Ritchie +"Unix never says 'please'." + -– Rob Pike + + http://en.wikipedia.org/wiki/Unix_philosophy + +* Worse is better. + +In the "Worse is better" design style, simplicity of both the interface and +the implementation is more important than any other attribute of the system — +including correctness, consistency and completeness. + +Simplicity + The design must be simple, both in implementation and interface. It is + more important for the implementation to be simpler than the interface. + Simplicity is the most important consideration in a design. +Correctness + The design must be correct in all observable aspects. It is slightly better + to be simple than correct. +Consistency + The design must not be overly inconsistent. Consistency can be sacrificed + for simplicity in some cases, but it is better to drop those parts of the + design that deal with less common circumstances than to introduce either + implementational complexity or inconsistency. +Completeness + The design must cover as many important situations as is practical. All + reasonably expected cases should be covered. Completeness can be sacrificed + in favor of any other quality. In fact, completeness must be sacrificed + whenever implementation simplicity is jeopardized. Consistency can be + sacrificed to achieve completeness if simplicity is retained; especially + worthless is consistency of interface. + + http://dreamsongs.com/WIB.html + Lisp: Good News, Bad News, How to Win Big + +* The right thing. + +The MIT approach (known as "The right thing"): + +Simplicity + The design must be simple, both in implementation and interface. It is + more important for the interface to be simpler than the implementation. +Correctness + The design must be correct in all observable aspects. Incorrectness is + simply not allowed. +Consistency + The design must be consistent. A design is allowed to be slightly less + simple and less complete to avoid inconsistency. Consistency is as important + as correctness. +Completeness + The design must cover as many important situations as is practical. All + reasonably expected cases must be covered. Simplicity is not allowed to + overly reduce completeness. + + http://dreamsongs.com/WIB.html + Lisp: Good News, Bad News, How to Win Big + +* YAGNI. + +"You aren't gonna need it" (or YAGNI for short) is the principle in extreme +programming that programmers should not add functionality until it is +necessary. + + http://en.wikipedia.org/wiki/You_ain%27t_gonna_need_it + +* DRY (DIE). + +Don't Repeat Yourself (DRY) or Duplication is Evil (DIE). + + * VCS allow multiple and diverging copies ("branches"). + * Source code generation. + + http://en.wikipedia.org/wiki/Don%27t_repeat_yourself + +* Do it yourself (DIY). + +Do it yourself (or DIY) is a term used to describe building, modifying, or +repairing of something without the aid of experts or professionals. + +when tasklist longer then people life mutch easy use already written libraries +then wrote own. + + http://en.wikipedia.org/wiki/Do_it_yourself + +* Once and Only Once (OAOO). + + + +* MoSCoW Method. + +The capital letters in MoSCoW stand for: + + * M - MUST have this (included in the current delivery timebox in order + for it to be a success). + * S - SHOULD have this if at all possible (critical to the success of the + project, but are not necessary for delivery in the current delivery + timebox). + * C - COULD have this if it does not affect anything else (nice to have). + * W - WON'T have this time but WOULD like in the future. + + http://en.wikipedia.org/wiki/MoSCoW_Method + +* Abandonware. + +Abandonware is a term used to describe computer software that is no longer +sold or supported, or whose copyright ownership may be unclear for various +reasons. While the term has been applied largely to older games, utility +software, etc. + + http://en.wikipedia.org/wiki/Abandonware + +* Separation of concerns. + +In computer science, separation of concerns (SoC) is the process of separating +a computer program into distinct features that overlap in functionality as +little as possible. A concern is any piece of interest or focus in a program. +Typically, concerns are synonymous with features or behaviors. Progress +towards SoC is traditionally achieved through modularity of programming and +encapsulation (or "transparency" of operation), with the help of information +hiding. Layered designs in information systems are also often based on +separation of concerns (e.g., presentation layer, business logic layer, data +access layer, database layer). + +HyperText Markup Language (HTML) and cascading style sheets (CSS) are +languages intended to separate style from content. + + http://en.wikipedia.org/wiki/Separation_of_concerns + +* Modular design. + +In systems engineering, modular design — or "modularity in design" — is an +approach that subdivides a system into smaller parts (modules) that can be +independently created and then used in different systems to drive multiple +functionalities. + + http://en.wikipedia.org/wiki/Modular_design + +* Occam's razor. + +"entia non sunt multiplicanda praeter necessitatem" + +Entities must not be multiplied beyond necessity. + +* Code and fix. + +Programmers immediately begin producing code. Bugs must be fixed before the +product can be shipped. + + http://en.wikipedia.org/wiki/Code_and_fix + +* Cowboy coding. + +Cowboy coding is a term used to describe software development where the +developers have autonomy over the development process. This includes control +of the project's schedule, algorithms, tools, and coding style. + +A cowboy coder can be a lone developer or part of a group of developers with +either no external management or management that controls only non-development +aspects of the project, such as its nature, scope, and feature set (the +"what", but not the "how"). + + http://en.wikipedia.org/wiki/Cowboy_coding + +* Extreme Programming. + + http://en.wikipedia.org/wiki/Extreme_Programming + +* Hollywood Principle. + +In computer programming, the Hollywood Principle is stated as "don't call us, +we'll call you." It has applications in software engineering; see also +implicit invocation for a related architectural principle. + + http://en.wikipedia.org/wiki/Hollywood_Principle + +* Inversion of control. + +Inversion of control, or IoC, is an abstract principle describing an aspect of +some software architecture designs in which the flow of control of a system is +inverted in comparison to procedural programming. + + http://en.wikipedia.org/wiki/Inversion_of_control + +* Literate programming. + + http://en.wikipedia.org/wiki/Literate_Programming + +* Model-driven architecture. + + http://en.wikipedia.org/wiki/Model-driven_architecture + +* Quick-and-dirty. + +Quick-and-dirty is a term used in reference to anything that is an easy way to +implement a workaround or "kludge." Its usage is popular among programmers, +who use it to describe a crude solution or programming implementation that is +imperfect, inelegant, or otherwise inadequate, but which solves or masks the +problem at hand, and is generally faster and easier to put in place than a +proper solution. + + http://en.wikipedia.org/wiki/Quick-and-dirty + +* Release early, release often. + +Release early, release often (sometimes abbreviated RERO) is a software +development philosophy that emphasizes the importance of early and frequent +releases in creating a tight feedback loop between developers and testers or +users. + + http://en.wikipedia.org/wiki/Release_early,_release_often + +* Test-driven development. + +Test-driven development (TDD) is a software development technique that relies +on the repetition of a very short development cycle: First the developer +writes a failing automated test case that defines a desired improvement or new +function, then produces code to pass that test and finally refactors the new +code to acceptable standards. + + http://en.wikipedia.org/wiki/Test-driven_development + +* Unified Process. + +The Unified Software Development Process or Unified Process is a popular +iterative and incremental software development process framework. The +best-known and extensively documented refinement of the Unified Process is the +Rational Unified Process (RUP). + + http://en.wikipedia.org/wiki/Unified_Process + +* Waterfall model. + + 1. Requirements specification + 2. Design + 3. Construction (AKA implementation or coding) + 4. Integration + 5. Testing and debugging (AKA Validation) + 6. Installation + 7. Maintenance + + http://en.wikipedia.org/wiki/Waterfall_model + +* Do it yourself. diff -r 95d5fafa0a88 -r 90e66cb8292a emacs.rst --- a/emacs.rst Thu Jun 10 15:02:56 2010 +0300 +++ b/emacs.rst Tue Jun 15 21:15:01 2010 +0300 @@ -45,6 +45,14 @@ know about line numbers and files - it just knows an error happened, and that's it. +*** Check if bug in ini file. + +First run Emacs without loading anything: + + $ emacs --no-init-file --no-site-file + +If bug not reproduced bug lies in ini files! + *** Binary Search. Select half of the file in a region, and M-x eval-region. Depending on whether diff -r 95d5fafa0a88 -r 90e66cb8292a emul.rst --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/emul.rst Tue Jun 15 21:15:01 2010 +0300 @@ -0,0 +1,13 @@ +-*- mode: outline; coding: utf-8 -*- + +* Game consoles. + +** MSX + +** NES + +** SNES + +** SEGA + +** NINDENDO64 diff -r 95d5fafa0a88 -r 90e66cb8292a gamepad.rst --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/gamepad.rst Tue Jun 15 21:15:01 2010 +0300 @@ -0,0 +1,17 @@ +-*- mode: outline; coding: utf-8 -*- + +* Linux. + + $ sudo apt-get install joystick + $ sudo apt-get install jscalibrator + $ sudo chmod 666 /dev/input/js0 + + $ modprobe joydev + + $ jscal /dev/input/js0 + $ jstest /dev/input/js0 + +* How play game with gamepad if thay not support gamepad? + + http://en.wikipedia.org/wiki/Xpadder + non-free, Windows only