The James White Manifesto

Taken from websages blog.

    == Rules ==
On Infrastructure
– There is one system, not a collection of systems.
– The desired state of the system should be a known quantity.
– The “known quantity” must be machine parseable.
– The actual state of the system must self-correct to the desired state.
– The only authoritative source for the actual state of the system is the system.
– The entire system must be deployable using source media and text files.

On Buying Software
– Keep the components in the infrastructure simple so it will be better understood.
– All products must authenticate and authorize from external, configurable sources.
– Use small tools that interoperate well, not one “do everything poorly” product.
– Do not implement any product that no one in your organization has administered.
– “Administered” does not mean saw it in a rigged demo, online or otherwise.
– If you must deploy the product, hire someone who has implemented it before to do so.

On Automation
– Do not author any code you would not buy.
– Do not implement any product that does not provide an API.
– The provided API must have all functionality that the application provides.
– The provided API must be tailored to more than one language and platform.
– Source code counts as an API, and may be restricted to one language or platform.
– The API must include functional examples and not requre someone to be an expert on the product to use.
– Do not use any product with configurations that are not machine parseable and machine writeable.
– All data stored in the product must be machine readable and writeable by applications other than the product itself.
– Writing hacks around the deficiencies in a product should be less work than writing the product’s functionality.

In general
– Keep the disparity in your architecture to an absolute minimum.
– Use Set Theory to accomplish this.
– Do not improve manual processes if you can automate them instead.
– Do not buy software that requires bare-metal.
– Manual data transfers and datastores maintained manually are to be avoided.

My own basic Git cheat sheet

Git Cheat Sheet

  • Create
    • Clone Repository: git clone url
    • Create new local repository: git init
  • Local Changes
    • Detect pending changes: git status
    • Add files to commit: git add -p <filename> or git add .
    • Commit code: git commit -a -m “Comment”
    • Get code: git pull
    • Push changes: git push
    • View History: git log  / git log -p <filename>
    • History/Blame: git blame <filename>
  • Branches, Merge & Rebase
    • Detect current branch: git branch
    • List all branches: git branch -av
    • Merge branch into current head: git merge <branch>
    • Rebase current head onto <branch>: git rebase <branch>

Git workflow:


PowerShell Modules: All you need to remember


Script Modules

A script module is a file (.psm1) that contains any valid Windows PowerShell code. Script developers and administrators can use this type of module to create modules whose members include functions, variables, and more.

Binary Modules

A binary module is a .NET Framework assembly (.dll) that contains compiled code. Cmdlet developers can use this type of module to create modules that contain cmdlets, providers, and more. (Existing snap-ins can also be used as binary modules.)

Manifest Modules

A manifest module is a module that includes a manifest (described later in this section) to describe its components, but that does not specify a root module in the manifest. A module manifest does not specify a root module when the ModuleToProcess key of the manifest is blank. In most cases, a manifest module also includes one or more nested modules using script modules or binary modules. A manifest module that does not include any nested modules can be used when you want a convenient way to load assemblies, types, or formats.

Dynamic Modules

A dynamic module is a module that does not persist to disk. This type of module enables a script to create a module on demand that does not need to be loaded or saved to persistent storage. By default, dynamic modules created with the New-Module cmdlet (described in the following sections) are intended to be short-lived and therefore cannot be accessed by the Get-Module cmdlet

Using Transfer utility in AWS SDK.NET

Useful Links

Upload files

Upload directory



Function to change encoding of a file in PowerShell

This is a function to change encoding of a file:

Vagrant basics

  • Software to install
  • Vagrant Tutorial:
  • HashiCorp’s Atlas box catalog:
  • Link to download manually a box:
  • Vagrant boxes cache folder: C:\Users\xxxx\.vagrant.d
  • Sample vagrantfile (it is better creating vagrantfile with vagrant init)
  • Commands to spawn Linux:

  • Commands to spawn Windows 7:

  •  Useful commands:

Useful MarkLogic links

Useful MarkLogic links: