Microsoft snaps up GitHub for $7.5 billion

microsoft-github-800x421

As we anticipated yesterday, Microsoft has reached an agreement to buy GitHub, the source repository and collaboration platform, in a deal worth $7.5 billion. The all-stock deal is expected to close by the end of the year, subject to regulatory approval in the US and EU.

Decade-old GitHub is built on Git, the open source version control software originally written by Linux creator Linus Torvalds. Git is a distributed version control system: each developer has their own repository that they make changes to, and these changes can be propagated between repositories to share those changes. GitHub provides a repository hosting service: a place to put those repositories so that other developers can readily access them. Since its inception, it has become a mainstay of the open source world, with countless projects—including Microsoft projects such as the Visual Studio Code text editor and the .NET runtime—using GitHub repositories as a place to publish their code to the world and coordinate collaborative development. In total, some 28 million developers use GitHub, and there are 85 million code repositories.

Microsoft has reportedly acquired GitHub

pplware_microsoft_github01-1024x498

Microsoft has reportedly acquired GitHub, and could announce the deal as early as Monday. Bloomberg reports that the software giant has agreed to acquire GitHub, and that the company chose Microsoft partly because of CEO Satya Nadella. Business Insider first reported that Microsoft had been in talks with GitHub recently.

GitHub is a vast code repository that has become popular with developers and companies hosting their projects, documentation, and code. Apple, Amazon, Google, and many other big tech companies use GitHub. Microsoft is the top contributor to the site, and has more than 1,000 employees actively pushing code to repositories on GitHub. Microsoft even hosts its own original Windows File Manager source code on GitHub. The service was last valued at $2 billion back in 2015, but it’s not clear exactly how much Microsoft has paid to acquire GitHub.

Microsoft has been rapidly investing in open source technology since Satya Nadella took over the CEO role. Microsoft has open sourced PowerShell, Visual Studio Code, and the Microsoft Edge JavaScript engine. Microsoft also partnered with Canonical to bring Ubuntu to Windows 10, and acquired Xamarin to assist with mobile app development.

Microsoft is also using the open source Git version control system for Windows development, and the company even brought SQL Server to Linux. Microsoft’s Visual Studio Code, which lets developers build and debug web and cloud applications, has soared in popularity with developers. Microsoft’s GitHub acquisition will likely mean we’ll start to see even closer integration between Microsoft’s developer tools and the service. At Build last month, Microsoft continued its close work with GitHub by integrating the service into the company’s App Center for developers.

Deferring Processing of Azure Service Bus Messages

Sometimes when you’re handling a message from a message queue, you realise that you can’t currently process it, but might be able to at some time in the future. What would be nice is to delay or defer processing of the message for a set amount of time.

Unfortunately, with brokered messages in  Azure Service Bus, there is no built-in feature to do this simply, but there are a few workarounds. In this post, we’ll look at four separate techniques: let the lock time out, sleep and abandon, defer the message, and resubmit the message.

Let the Lock Time Out

The simplest option is doing nothing. When you get your BrokeredMessage, don’t call Complete or Abandon. This will mean that the lock on the message will eventually time out, and it will become available for processing again once that happens. By default the lock duration for a message is 1 minute, but this can be configured for a queue by using the QueueDescription.LockDuration property.

The advantage is that this is a very simple way of deferring re-processing the message for about a minute. The main disadvantage is that the time is not so easy to control as the lock duration is a property of the queue, not the message being received.

In the following simple example, we create a queue with a lock duration of 30 seconds, send a message, but then never actually complete or abandon it in the handler. This results in us seeing the same message getting retried with an incrementing Delivery Count until eventually it is dead-lettered automatically on the 10th attempt.

// some connection string
string connectionString = "";
const string queueName = "TestQueue";

// PART 1 - CREATE THE QUEUE
var namespaceManager = 
    NamespaceManager.CreateFromConnectionString(connectionString);

// ensure it is empty
if (namespaceManager.QueueExists(queueName))
{
    namespaceManager.DeleteQueue(queueName);
}
var queueDescription = new QueueDescription(queueName);
queueDescription.LockDuration = TimeSpan.FromSeconds(30);
namespaceManager.CreateQueue(queueDescription);

// PART 2 - SEND A MESSAGE
var body = "Hello World";
var message = new BrokeredMessage(body);
var client = QueueClient.CreateFromConnectionString(connectionString, 
                                                    queueName);
client.Send(message);

// PART 3 - RECEIVE MESSAGES
// Configure the callback options.
var options = new OnMessageOptions();
options.AutoComplete = false; // we will call complete ourself
options.AutoRenewTimeout = TimeSpan.FromMinutes(1); 

// Callback to handle received messages.
client.OnMessage(m =>
{
    // Process message from queue.
    Console.WriteLine("-----------------------------------");
    Console.WriteLine($"RX: {DateTime.UtcNow.TimeOfDay} - " + 
                      "{m.MessageId} - '{m.GetBody()}'");
    Console.WriteLine($"DeliveryCount: {m.DeliveryCount}");

    // Don't abandon, don't complete - let the lock timeout
    // m.Abandon();
}, options);

Sleep and Abandon

If we want greater control of how long we will wait before resubmitting the message, we can explicitly call abandon after sleeping for the required duration. Sadly there is no AbandonAfter method on brokered message. But it’s very easy to wait and then call Abandon. Here we wait for two minutes before abandoning the message:

client.OnMessage(m =>
{
    Console.WriteLine("-----------------------------------");
    Console.WriteLine($"RX: {DateTime.UtcNow.TimeOfDay} -" + 
                      " {m.MessageId} - '{m.GetBody()}'");
    Console.WriteLine($"DeliveryCount: {m.DeliveryCount}");

    // optional - sleep until we want to retry
    Thread.Sleep(TimeSpan.FromMinutes(2));

    Console.WriteLine("Abandoning...");
    m.Abandon();

}, options);

Interestingly, I thought I might need to periodically call RenewLock on the brokered message during the two minute sleep, but it appears that the Azure SDK OnMessage function is doing this automatically for us. The down-side of this approach is of course that our handler is now in charge of marking time, and so if we wanted to hold off for an hour or longer, then this would tie up resources in the handling process, and wouldn’t work if the computer running the handler were to fail. So this is not ideal.

Defer the Message

It turns out that BrokeredMessage has a Defer method whose name suggests it can do exactly what we want – put this message aside for processing later. But, we can’t specify how long we want to defer it for, and when you defer it, it will not be retrieved again by the OnMessage function we’ve been using in our demos.

So how do you get a deferred message back? Well, you must remember it’s sequence number, and then use a special overload of QueueClient.Receive that will retrieve a message by sequence number.

This ends up getting a little bit complicated as now we need to remember the sequence number somehow. What you could do is post another message to yourself, setting the ScheduledEnqueueTimeUtc to the appropriate time, and that message simply contains the sequence number of the deferred message. When you get that message you can call Receive passing in that sequence number and try to process the message again.

This approach does work, but as I said, it seems over-complicated, so let’s look at one final approach.

Resubmit Message

The final approach is simply to Complete the original message and resubmit a clone of that message scheduled to be handled at a set time in the future. The Clone method on BrokeredMessage makes this easy to do. Let’s look at an example:

client.OnMessage(m =>
{
    Console.WriteLine("--------------------------------------------");
    Console.WriteLine($"RX: {m.MessageId} - '{m.GetBody()}'");
    Console.WriteLine($"DeliveryCount: {m.DeliveryCount}");

    // Send a clone with a deferred wait of 5 seconds
    var clone = m.Clone();
    clone.ScheduledEnqueueTimeUtc = DateTime.UtcNow.AddSeconds(5);
    client.Send(clone);

    // Remove original message from queue.
    m.Complete();
}, options);

Here we simply clone the original message, set up the scheduled enqueue time, send the clone and complete the original. Are there any downsides here?

Well, it’s a shame that sending the clone and completing the original are not an atomic operation, so there is a very slim chance of us seeing the original again should the handling process crash at just the wrong moment.

And the other issue is that DeliveryCount on the clone will always be 1, because this is a brand new message. So we could infinitely resubmit and never get round to dead-lettering this message.

Fortunately, that can be fixed by adding our own resubmit count as a property of the message:

client.OnMessage(m =>
{
    int resubmitCount = m.Properties.ContainsKey("ResubmitCount") ? 
                       (int)m.Properties["ResubmitCount"] : 0;

    Console.WriteLine("--------------------------------------------");
    Console.WriteLine($"RX: {m.MessageId} - '{m.GetBody<string>()}'");
    Console.WriteLine($"DeliveryCount: {m.DeliveryCount}, " + 
                      $"ResubmitCount: {resubmitCount}");

    if (resubmitCount > 5)
    {
        Console.WriteLine("DEAD-LETTERING");
        m.DeadLetter("Too many retries", 
                     $"ResubmitCount is {resubmitCount}");
    }
    else
    {
        // Send a clone with a deferred wait of 5 seconds
        var clone = m.Clone();
        clone.ScheduledEnqueueTimeUtc = DateTime.UtcNow.AddSeconds(5);
        clone.Properties["ResubmitCount"] = resubmitCount + 1;
        client.Send(clone);

        // Remove message from queue.
        m.Complete();
    }
}, options);

Happy coding!

London launches world’s first contactless payment scheme for street performers

Charlotte_Campbell_London

Here’s a casualty of the cashless society you might not have previously thought of: the humble street performer. After all, if more of us are paying our way with smartphones and contactless cards, how can we give spare change to musicians on the subway? London has one solution: a new scheme that outfits performers with contactless payment terminals.

The project was launched this weekend by the city’s mayor, Sadiq Khan, and is a collaboration with Busk In London (a professional body for buskers) and the Swedish payments firm iZettle (which was bought this month by PayPal for $2.2 billion). A select few performers have been testing iZettle’s contactless readers on the streets for the past few weeks, and Khan now says the scheme will be rolled out across London’s 32 boroughs.

Charlotte Campbell, a full-time street performer who was part of the trial, told BBC News that the new tech “had a significant impact on contributions.” Said Campbell: “More people than ever tap-to-donate whilst I sing, and often, when one person does, another follows.”

The readers need to be connected to a smartphone or tablet, and accept payments of fixed amounts (set by the individual performer). They work with contactless cards, phones, and even smartwatches. There’s no detail yet on how many readers will be provided to London’s street performers, or whether they will have to pay for the readers themselves.

Although individuals do sometimes set up their own contactless payment systems (and in China, it’s not uncommon to see street performers and beggars use QR codes to solicit mobile tips), this seems to be the first scheme of its kind spearheaded by a city authority.

Microsoft Buys Conversational AI Company Semantic Machines

SemanticMachines

In a blog post, Microsoft Corporate Vice President and Chief Technology Officer of AI & Research David Ku announced the acquisition of Berkeley, California-based conversational AI company Semantic Machines. The natural language processing technology developed by Semantic Machines will be integrated into Microsoft’s products like Cortana and the Azure Bot Service.

On its website, Semantic Machines says that existing natural language systems such as Apple Siri, Microsoft Cortana and Google Now only understands commands, but not conversations. However, Semantic Machines' technology understands conversations rather than just commands. Some of the most typical commands that digital assistants can handle today include weather reports, music controls, setting up timers and creating reminders. “For rich and effective communication, intelligent assistants need to be able to have a natural dialogue instead of just responding to commands,” said Ku.

Microsoft turns SharePoint into the simplest VR creation tool yet

SharePoint_spaces

Microsoft is sticking with its pragmatic approach to VR with SharePoint spaces, a new addition to its collaboration platform that lets you quickly build and view Mixed Reality experiences. It's a lot like how PowerPoint made it easy for anyone to create business presentations. Sharepoint spaces features templates for things like a gallery of 3D models or 360-degree videos, all of which are viewable in Mixed Reality headsets (or any browser that supports WebVR). While they're certainly not complex virtual environments, they're still immersive enough to be used for employee training, or as a quick virtual catalog for your customers.

"Until now, it has been prohibitively complex and costly to develop customized MR apps to address these and other business scenarios," wrote Jeff Teper, Microsoft's corporate VP for OneDrive, SharePoint and Office, in a blog post today. "SharePoint spaces empower creators to build immersive experiences with point-and-click simplicity."

Given, When, Then

Given-When-Then is a style of representing tests specifying a system's behavior. It's an approach developed by Dan North and Chris Matts as part of Behavior-Driven Development (BDD). It appears as a structuring approach for many testing frameworks such as Cucumber. You can also look at it as a reformulation of the Four-Phase Test pattern.

The essential idea is to break down writing a scenario (or test) into three sections:

  • The given part describes the state of the world before you begin the behavior you're specifying in this scenario. You can think of it as the pre-conditions to the test.
  • The when section is that behavior that you're specifying.
  • Finally the then section describes the changes you expect due to the specified behavior.

Since we're talking about using examples as specifications, it makes sense to show this with an example

Feature: User trades stocks
  Scenario: User requests a sell before close of trading
    Given I have 100 shares of MSFT stock
       And I have 150 shares of APPL stock
       And the time is before close of trading

    When I ask to sell 20 shares of MSFT stock
     
     Then I should have 80 shares of MSFT stock
      And I should have 150 shares of APPL stock
      And a sell order for 20 shares of MSFT stock should have been executed
  

The above example uses Cucumber, which a popular way of writing BusinessFacingTests but you can use the Given-When-Then style with any kind of tests. Some people like to put Given-When-Then as comments to mark informal blocks inside unit tests. I've also seen this convention to structure informal prose.

It's usual with this approach to see "ands" used to combine multiple expressions within each clause.

I've characterized the given as a description of the pre-condition state because that's the way I prefer to think of it. A testing framework, however, interprets the givens as a set of commands to bring the system-under-test into the correct state before executing the when command. Testing frameworks provide various query methods for the then commands - these should be free of side-effects.

Although Given-When-Then style is symptomatic to BDD, the basic idea is pretty common when writing tests or specification by example. Meszaros describes the pattern as Four-Phase Test. His four phases are Setup (Given), Exercise (When), Verify (Then) and Teardown. Bill Wake came up with the formulation as Arrange, Act, Assert.

7 Popular Unit Test Naming Conventions

Following are 7 popular unit tests naming conventions that are found to be used by majority of developers and compiled from above pages:

  1. MethodName_StateUnderTest_ExpectedBehavior: There are arguments against this strategy that if method names change as part of code refactoring than test name like this should also change or it becomes difficult to comprehend at a later stage. Following are some of the example:
    • isAdult_AgeLessThan18_False
    • withdrawMoney_InvalidAccount_ExceptionThrown
    • admitStudent_MissingMandatoryFields_FailToAdmit
  2. MethodName_ExpectedBehavior_StateUnderTest: Slightly tweeked from above, but a section of developers also recommend using this naming technique. This technique also has disadvantage that if method names get changed, it becomes difficult to comprehend at a later stage. Following is how tests in first example would read like if named using this technique:
    • isAdult_False_AgeLessThan18
    • withdrawMoney_ThrowsException_IfAccountIsInvalid
    • admitStudent_FailToAdmit_IfMandatoryFieldsAreMissing
  3. test[Feature being tested]: This one makes it easy to read the test as the feature to be tested is written as part of test name. Although, there are arguments that the “test” prefix is redundant. However, some sections of developer love to use this technique. Following is how the above tests would read like if named using this technique:
    • testIsNotAnAdultIfAgeLessThan18
    • testFailToWithdrawMoneyIfAccountIsInvalid
    • testStudentIsNotAdmittedIfMandatoryFieldsAreMissing
  4. Feature to be tested: Many suggests that it is better to simply write the feature to be tested because one is anyway using annotations to identify method as test methods. It is also recommended for the reason that it makes unit tests as alternate form of documentation and avoid code smells. Following is how tests in first example would read like if named using this technique:
    • IsNotAnAdultIfAgeLessThan18
    • FailToWithdrawMoneyIfAccountIsInvalid
    • StudentIsNotAdmittedIfMandatoryFieldsAreMissing
  5. Should_ExpectedBehavior_When_StateUnderTest: This technique is also used by many as it makes it easy to read the tests. Following is how tests in first example would read like if named using this technique:
    • Should_ThrowException_When_AgeLessThan18
    • Should_FailToWithdrawMoney_ForInvalidAccount
    • Should_FailToAdmit_IfMandatoryFieldsAreMissing
  6. When_StateUnderTest_Expect_ExpectedBehavior: Following is how tests in first example would read like if named using this technique:
    • When_AgeLessThan18_Expect_isAdultAsFalse
    • When_InvalidAccount_Expect_WithdrawMoneyToFail
    • When_MandatoryFieldsAreMissing_Expect_StudentAdmissionToFail
  7. Given_Preconditions_When_StateUnderTest_Then_ExpectedBehavior: This approach is based on naming convention developed as part of Behavior-Driven Development (BDD). The idea is to break down the tests into three part such that one could come up with preconditions, state under test and expected behavior to be written in above format. Following is how tests in first example would read like if named using this technique:
    • Given_UserIsAuthenticated_When_InvalidAccountNumberIsUsedToWithdrawMoney_Then_TransactionsWillFail

Google AI can make calls for you

During the on-stage demonstration, Google played calls to a number of businesses including a hair salon and a Chinese restaurant. At no point did either of the people on the other end of the line appear to suspect that the entity they were interacting with was a bot. And how could they when the Assistant would even throw in random "ums", "ahhs" and other verbal fillers people use when they're in the middle of a thought? According to the company, it's already generated hundreds of similar interactions over the course of the technology's development.

MongoDb example

Simple example for MongoDB. Save and retrieve data from Azure Cosmos DB.

Create an Azure Cosmos Db as MongoDb

For creating a new MongoDb on Azure, search from the list of resources, Azure Cosmos Db. Then Add a new database and you see the following screen.

Add new CosmosDB

Overview

When you created a new MongoDb, you see an Overview where there are general information about how many queries the database did (split on insert, update, cancel, query, count, others).

Azure Overview

Under Connection String you have the connection to use in your application. In this project you insert in Program.cs the connection string in the variable called connectionString.

DataExplorer

You can explorer all data in your Mongo database. Click on Data Explorer and you can see everything. Also, you can execute same queries.

Azure CosmosDb Data Explorer

You find an example application on my GitHub.

Advertsing

125X125_06

Planet Xamarin

Planet Xamarin


Subscribe to our mailing list

* indicates required


TagCloud

MonthList