The Net is indeed vast and infinite…

Many times alternatives for version control systems are on topic, Git is a viable candidate. Arguments are not enough, though. One must answer the questions regarding then whats and hows?
Let us lay out a project utilizing Git for versioning source code, artefacts and assets etc.

First thing to mention: its distributed nature is not the first thing to talk about. It is the core feature, but not the most important quality to consider first. At the beginning it should be shown beforehand that it is able to fulfill the requirements of version control at all.

Revisions

In addition to remote repositories, Git also treats each working copy as a repository, in fact, they are local repositories per se. This makes every desired state perfectly revisionable, even local ones. On the file system level, only one particular snapshot (e.g. development state) is available, but you can take arbitrary snapshots. Commit and update refers to the interaction within this local repository.

Branching

Having a desired changeset, diff to share, you can use the push and pull operations to branch and merge between repositories available on the network. So you can for example push your local changes to the repository you were forking it in the first place from, or you can pull and merge the changes available in between repositories.
Please note that we are still considering a centralized management of the branching strategy. I.e. there can be several team level but one project level branch, and there can be additional release branches for each released revision (and their follow up bugfixes), and there can be sandbox forks to play around, and so on, but all in all, there are rules for where you can push to and pull from, enforced by rules of thumb (a.k.a process), hierarchy of trust (a.k.a review) and access control (a.k.a roles).

Who does the pushing and pulling, and more importantly who resolves conflicts? Git allows a great deal of flexibility here:
You can have dedicated people responsible for pushing all the changes upstream or pulling all the changes from downstream, resolving conflicts as they arise. Or you can have each person responsible for pushing each change from downstream to the top by following the process, getting reviews and acquiring required roles, but also resolving conflicts as they arise.
And a mixed approach is also feasible where for example team level changes are usually not branched but just pushed into the master repository, albeit changes which should go into release branches are pulled by individuals responsible for the release branch.

Distributed

So wherein lies the distributed nature of Git? By treating everything as a repository and giving flexibility on how to distribute responsibilities, upstream and downstream become relative terms. For the individual a clear hierarchy remains, can pull safe changes, and push resolved revisions. On the team level sub-teams and ad-hoc working groups find it intuitive to share code at any time, or just to fork a sandbox repository which can evolve on its own later on. Git can basically do whatever you expect from a centralized revision control system, but it heavily supports branching and merging across revisions. It does not force you to look at the project from the same perspective.

The bad

If you need tools to work with Git, its command line client is indeed sophisticated and once getting used to the terminology it serves as the best Swiss knife. However, GUI tools and enterprise integration is evolving at its best, you better check your environment and requirements, especially paying attention to the needs of every single one on the project beforehand.

QAssert is a powerful, easy-to-use, JavaScript assertion suite. In contrast to console.assert() it enables you to report failures via AJAX. It gives you also powerful assertion functions and is cross-browser compatible.
It can be used in both in unit, functional and manual tests, and notably also
in production code.

QAssert is especially useful for regression testing: You can place assertions for any assumption that is made in the JavaScript logic. While running the code assertion violations will be reported via AJAX and regressions become quickly visible. To give you an example how to safeguard against unexpected DOM changes:

var $panel = $("#menuPanel");
$panel.assert().load("/");
$.assert($panel.text().length);


It is a simple drop-in jQuery plugin. It is disabled by default. To enable it and to see assertions:

$.assertSetup("/assertReporter"); // Required only once.
$.assert(false)

As a result:

• You will se the assertion failure in the console including a full stack trace (Assertion failed: false undefined {anonymous}()@file:///D:/Dropbox/dev/qassert/qassert/qassert.js:708 …)
• You will see an AJAX call being made to the given URL

It is highly configurable:

$.assertSetup({
enabled: true,
ajax: "/fooBar", // You can also pass a full $.ajax() parameter object here!
catchGlobalErrors: true, // This will report ALL uncatched exceptions too!
contextCallback: function(value, message, stacktrace) {return {version: app.version, locale: app.locale}}, // Enhances the reported data
log: myLogFunction, // Used to log failures locally, by default to the console.
title: "Assertion sucked up:"
});


It has a convenient API:

• $.fn.assert(message, sizeOrCallback): Chained selector assertions.
• $.assert(value, message): Boolean assertion.
• $.assertDeepEquals(value, expected, message): Recursive equality assertion.
• $.assertEmpty(value, message): Empty assertion.
• $.assertEquals(value, expected, message): Equality assertion, no recursion.
• $.assertIs(value, type, message): Type assertion.
• $.assertNot(value, message): Boolean assertion for false.
• $.assertNotDeepEquals(value, expected, message): Recursive unequality assertion.
• $.assertNotEmpty(value, message): Non-empty assertion.
• $.assertNotEquals(value, expected, message): Unequality assertion, no recursion.
• $.assertNotIs(value, type, message): Type assertion inverted.
• $.assertNotSame(value, expected, message): Strict unequality assertion.
• $.assertSame(value, expected, message): Strict equality assertion.

See the documentation and test cases.
Join the development: https://github.com/gaboom/qassert

Here is the code you get a form with, you can submit php code, it gets evaluated on the server.
SECURITY WARNING: command(s) below will be all executed in PHP’s server context! Deny public acces.

<!doctype html>
<html lang="en">
    <head>
        <meta charset="utf-8">
        <title>PHP evaluator</title>
    </head>
    <body>
        <div>
            <?php
            $function = "eval";
            $arguments = "return true";
            if ($_SERVER['REQUEST_METHOD'] == "POST") {
                $result = null;
                $function = $_POST["function"];
                $arguments = $_POST["arguments"];
                switch ($function) {
                    case "eval":
                        $result = eval($arguments . ";");
                        break;
                    default:
                        $result = $function($arguments);
                }
                echo "<hr/>";
                var_dump($result);
                echo "<hr/>";
                print_r($result);
                echo "<hr/>";
                echo($result);
            }
            ?>
        </div>
        <hr>
        SECURITY WARNING: command(s) below will be all executed in PHP's server context! Deny public acces.
        <form method="POST">
            <textarea name="arguments" style="width: 600px; height:200px"><?php echo $arguments ?></textarea>
            <br/>
            Function: <input type="text" name="function" value="<?php echo $function ?>" />
            <button>EXECUTE</button>
        </form>
    </body>
</html>

Writing down usernames and passwords with a pen is insecure in so many ways I do not attempt to count.
The sheer count of passwords however, forces most persons to store them somewhere, instead of keeping all of them just in your head.
The digital solution is to protect the passwords with another password in sort of a vault (e.g. in a file on a password protected disk, encrypted volume or file, password storage program) [Please note: browsers store passwords almost cleartext by default!]

Sometimes you are still forced to keep a password written up quick and easily in an unencrypted environment, like a piece of paper. (Developing and memorizing secret code language is rather difficult to accomplish this.)
The trick is to write down the password, but with a simple to remember twist!

For each password pair you can see first an example of a cleartext password, then the transformed version:

• alaudZAPP1 – alXZaudZAPP12
• persepoleS – pe9lrsepoleSq
• Bo23LOwf3 – BobT23LOwf34

You can insert at the very same position(s) random letters to make the text written down unusable. In this example I choose to insert two the after the first two letters, then one at the end.
Looking at the passwords on the right, remembering your scheme, you can easily re-type (decode) the original passwords but leaving an attacker with an obfuscated one.

WARNING: This method is by far not as safe as a fully encrypted password, and offers only a better-than-nothing protection. Common patterns in your password will become visible by this! Never re-use a password, this method reveals any such mistake, also making it obvious how you encoded all your other passwords written down.

For a release sign-off

• Do all unit, automated and regression tests run?
• What is the status of outstanding bugs?
• Are all changes demonstrated to stakeholders?

For a design sign-off

• Are all transformations from the input domain to the output domain possible? Identify first risky and/or complex ones.
• Are all our needs supported by an API?
• Is our API supporting all requirements?
• BONUS: If it takes more than two days to complete, does a task breakdown exist?