"Clone in Desktop" doesn't launch GitHub for Windows

"Clone in Desktop" wasn't launching GitHub for Windows.
Fortunately Joe Freeman solved it.

You either
a. Log in to GitHub in the Web Browser before clicking the "Clone in Desktop" link
b. Drag the URL of the repository to GitHub for Windows

Galaxy Tab S doesn't connect to ADB (Android Device Bridge)

After receiving a new Galaxy Tab S, I noticed it would not connect to Eclipse or ADB for debugging.

(I had enabled Developer options by clicking on Settings > General > About Device > Android Version 7 times).

The solution is that you have to download the USB driver from Samsung's site. This then enables the following drivers:

Sitecore 6.6, Web API 1.2 and the message "An attempted to execute remote call was declided, because current mode is 'off'"

We are running Sitecore with MVC and installed the Web API 1.2.

When accessing the URL
http://<hostname>/-/item/v1/?query=/sitecore/content/*

from within Chrome and Postman it was running an error page.
After some extensive reading, experimenting, writing a custom pipeline processor and using Reflector, I finally solved it.

Firstly I turned on logging to ALL in App_Config\Sitecore.log4net.config.

This showed the following error message in the event log:

"An attempted to execute remote call was declided, because current mode is 'off'"

er... this should mean "declined", but never mind. Carrying on:

Reflector indicated that the CheckMode processor found the itemwebapi.mode setting was turned to "Off".

But hold on, my settings were on:
Include\Sitecore.ItemWebApi.config:

<site name="website">
        <patch:attribute name="itemwebapi.mode">StandardSecurity</patch:attribute>
        <patch:attribute name="itemwebapi.access">ReadOnly</patch:attribute>
        <patch:attribute name="itemwebapi.allowanonymousaccess">true</patch:attribute>
      </site>

So then I wrote a processor to fit within the pipeline to evaluate the problem.
The following class was written and added to a class library:

using System;
using System.Diagnostics;
using Sitecore.Diagnostics;
using Sitecore.Pipelines.HttpRequest;

namespace TestPipeline
{
    public class TestProcessor : HttpRequestProcessor
    {
        public override void Process(HttpRequestArgs args)
        {
            var context = args.Context.Items["Sitecore.ItemWebApi.Context"];
            Console.WriteLine("Hello World");
        }
    }
}

the class library requires references to Sitecore.Kernel and System.Web.

Using reflector, it can be seen that the Web API settings are loaded in SetRuntimeSettings, which runs after SiteResolver:

<processor type="Sitecore.ItemWebApi.Pipelines.HttpRequest.SetRuntimeSettings, Sitecore.ItemWebApi" patch:after="processor[@type='Sitecore.Pipelines.HttpRequest.SiteResolver, Sitecore.Kernel']" />

Therefore the pipeline was inserted after SiteResolver:

<processor type="Sitecore.Pipelines.HttpRequest.SiteResolver, Sitecore.Kernel" />
<processor type="TestPipeline.TestProcessor, TestPipeline" />
<processor type="Sitecore.Pipelines.HttpRequest.UserResolver, Sitecore.Kernel" />

A debugger was then attached to the wp3 process and a breakpoint put within the processor.
Looking at args.Context.Items["Sitecore.ItemWebApi.Context"].Settings.Mode it was indeed turned to off and not StandardSecurity.

It was then determined that in the Web API config the site had the default sitename:

<site name="website">

whereas in Include\Sitecore.SiteDefinition.config the sitename was patched to something else:

<configuration xmlns:patch="http://www.sitecore.net/xmlconfig/">
  <sitecore>
    <sites>
      <site br="" name="checkout" patch:instead="site[@name='website']">
</site></sites></sitecore></configuration>b

Removing Include\Sitecore.SiteDefinition.config fixed the problem.
To keep the file, the following attributes were added:

itemwebapi.mode="StandardSecurity"
itemwebapi.access="ReadOnly"
itemwebapi.allowanonymousaccess="true"

Solved: The WebAPI config was assuming the default site name "website" whereas this had been configured to something else.