Зачастую мы сами себе создаем трудности и в первую очередь тем, что считаем себя самыми умными.

Where are all the major log files located?

All log files are located in /var/log directory. In that directory, there are specific files for each type of logs. For example, system logs, such as kernel activities are logged in syslog file.

• Some of the most common log files in that directory is : 
• In directory apt there is a file history.log which saves all the package installation and removal information even the initial system build as Live CD. You can open this file to see this very interesting file. 
• In directory dist-upgrade there is a file apt.log which logs the information during distribution upgrades 
• In directory installer the log files which are created during installation can be found. 
• There is an apport.log file which saves information about crashes in your system and reporting them. 
• The file auth.log includes information about the authentication activities such as when you authenticate as root user via sudo. 
• The file dpkg.log saves the low level details of package installation and removal related with dpkg. You might be aware that, Apt system depends on dpkg for package installation and removal. 
• boot.log includes information of each booting. 
• kern.log saves kernel information such as warnings, errors etc. 
• alternatives.log includes the history of all the alternatives set by various packages and there removal via update-alternatives command. 
• Another important log file is Xorg.log which include information about the graphics driver, it's failures, warnings etc. 

Some other types of Log files may be there depending on your installed packages. For example, My system also includes a log files epoptes.log which will only be there if you install epoptes package.

How do I lock the screen from a terminal?

gnome-screensaver-command --lock

-l, --lock                 Tells the running screensaver process to lock the screen immediately
-a, --activate             Turn the screensaver on (blank the screen)

d3 - A JavaScript visualization library for HTML and SVG

Ubuntu terminal shortcuts

CTRL + S - freezes the screen and stops any display on the screen from continuing (equivalent to a no-scroll key) (sometimes takes a moment to work)
CTRL + Q - un-freezes the screen and lets screen display continue

CTRL + \ - same as CTRL - C but stronger (used when terminal doesn't respond)
CTRL + L - clear display

Movement
line: CTRL+ A / CTRL + E
character: CTRL + B / CTRL + F

Search
start: CTRL+ R
cancel: CTRL+ G

Edit

Copy / Paste

CTRL + SHIFT + C / CTRL + SHIFT + V

Change Case
capitalize word: ALT + C
lowercase / uppercase word: ALT + L / ALT + U

Transpose
characters: CTRL+ T
words: ESC + T
Undo
CTRL + _

ALT + R - Undo all changes made to this line

Insert
Line break (\n): CTRL+ V + Return

Delete
character: CTRL + H / CTRL + D
word: CTRL+W / ALT + D
line: CTRL + U / CTRL + K

Auto Completion
command + Tab + Tab
show all possible completions: ALT + ?
insert all possible completions: ALT + *
attempt to complete filename: ALT + \
yank last argument of previous command: ALT + .
repeats the last argument of the previous command: command !$

Clear a mistyped invisible password on a terminal
CTRL + U

http://www.gnu.org/software/bash/manual/bashref.html#Bindable-Readline-Commands

stty -a

http://linux.die.net/man/1/stty

reset

Lean-Agile Acceptance Test-Driven Development. Better Software Through Collaboration - Pugh K. - 2011

Although acceptance testing has been around for a long time, it was reinvigorated by extreme programming. Its manifestations include ATDD as described in this book, example-driven development (EDD) by Brian Marick, behavior-driven development (BDD) by Dan North, story test-driven development (SDD) by Joshua Kerievsky of Industrial Logic, domain-driven design (DDD) by Eric Evans, and executable acceptance test-driven development (EATDD)

Tests for business rules can be executed in at least these four ways:

• Creation through the user interface of a transaction that invokes the business rule
• Development of a user interface that directly invokes the business rule 
• A unit test implemented in a language’s unit testing framework
• An automated test that communicates with the business rule module

• The structure of a test is 
• Given <setup> 
• When <action or event> 
• Then <expected results>
• For calculation tests, the structure is 
• Given <input> 
• When <computation occurs> 
• Then <expected results> 
• Following are three types of tables: 
• Calculation—Gives result for particular input 
• Data—Gives data that should exist (or be created if necessary) 
• Action—Performs some action

• Create a test for each exception and alternative in a use case. 
• Do not automate everything. 
• Run tests at multiple levels. 
• Create a working system early to check against objectives.

• When creating and implementing tests, consider the following: 
• Develop tests and automation separately. Understand the test first, and then explore how to automate it.
• Automate the tests so that they can be part of a continuous build.
• Don’t put test logic in the production code. Tests should be completely separate from the production code. 
• As much as practical, cover 100% of the functional requirements in the acceptance tests.

In structuring tests, remember the following:

• Tests should follow the Given-When-Then or the Arrange-Act-Assert.
• Keep tests simple. 
• Only have the essential detail in a test. 
• Avoid lots of input and output columns. Break large tables into smaller ones, or show common values in the headers.
• Avoid logic in tests. 
• Describe the intent of the test, not just a series of steps.

• Equivalence partitioning, which divides inputs into groups that should exhibit similar behavior.
• Boundary value analysis, which tests values at the edge of each equivalence partition.
• State transition testing checks the response from a system that depends on its state. 
• Use case testing to check all paths through a use case. 
• Decision table testing for complex business rules.  Often, the decision table is presented in the opposite format, where rows and columns are interchanged from the format used in this book. 

• Who—The triad—customer, developer, and tester communicating and
• collaborating
• What—Acceptance criteria for projects and features, acceptance tests for
• stories
• When—Prior to implementation—either in the iteration before or up to
• one second before, depending on your environment
• Where—Created in a joint meeting, run as part of the build process
• Why—To effectively build high-quality software and to cut down the
• amount of rework
• How—In face-to-face discussions, using Given/When/Then and examples

Framework Websites

JBehave http://jbehave.org/
Fit http://fit.c2.com/
FitNesse http://fitnesse.org/
Easyb http://www.easyb.org/
Cucumber http://cukes.info
Robot http://code.google.com/p/robotframework/
Arbiter http://arbiter.sourceforge.net/
Concordian http://www.concordion.org/
Selenium http://seleniumhq.org
Watir http://watir.com/

Other frameworks at: http://www.opensourcetesting.org/functional.php


http://www.acceptancetestdrivendevelopment.com/

Неделя с Flask

http://klen.github.com/some-flask-things-ru.html