Creating labels for input elements in React

When creating forms in React, you’ll often want to add labels to go with your input elements. If you’re used to doing this in HTML, you’d probably start by entering JSX that looks like this:

<label for="myInput">My Input</label>
<input id="myInput" type="text" />

But when you load up a component containing this code, you’ll find that it doesn’t work. This is because React doesn’t have a for property in its label element.  Instead, it has an htmlFor property, which matches the property name used by the label element in the HTML DOM.

So to add a labels to your React forms, you’ll just need to do something like this:

<label htmlFor="myInput">My Input</label>
<input id="myInput" type="text" />

and you’ll end up with the generated HTML you’re expecting. The reason for this is simple: for is a reserved keyword in JavaScript, and since JSX is embedded in JavaScript, it avoids using any of JavaScript’s reserved keywords. This is the same reason that React components use the className attribute instead of class.

Azure DocumentDB vs Azure SQL Database

Azure DocumentDB and Azure SQL Database are two of the primary cloud storage choices available on Azure. Choosing between them isn’t always easy – there is overlap in their capabilities, and for many applications either choice would work. We’ll outline some of the differences so you can choose the one that’s right for your circumstances.

If you’re looking for a comparison between Azure DocumentDB and Azure Table Storage, you can find it here.

Executive Summary

If you don’t have time to read the full comparison, here’s what it boils down to:

Azure DocumentDB is, as its name implies, a document database. In this respect, it is similar to MongoDB. It stores collections of documents that don’t adhere to a fixed schema. Azure DocumentDB is less expensive than Azure SQL Database, and if you expect your application to operate at massive scale, DocumentDB will scale up more easily.

Azure SQL Database is essentially a full cloud version of Microsoft SQL Server. There are some cases where Azure SQL is missing some SQL Server capabilities. You can find a good list in this blog post. For most applications, you can use Azure SQL Database as a drop in replacement for SQL Server. This means you can use your familiar SQL Server tools, and if you’re a seasoned developer of SQL queries, you’ll feel right at home with with Azure SQL. There are a couple of caveats, however – Azure SQL Database is significantly more expensive than DocumentDB, and it is more difficult (and in a extreme cases, impossible) to scale an Azure SQL Database up as far as DocumentDB.

Read on for a more detailed comparison.

Azure DocumentDB

DocumentDB is a relatively new addition to the Azure family. Introduced in August of 2014, it is a distributed document database. It can be used in scenarios where other document stores such as MongoDB would be a good fit.

Benefits:

  • Documents are stored in JSON format, which makes them very easy to work with in a wide variety of programming languages. The lack of a schema means that not all documents in a collection need to have the same fields.
  • Offers a range of consistency levels, ranging from strong consistency to eventual consistency. This makes it possible to adjust consistency to suit your application’s needs.
  • MongoDB protocol support: Applications designed to be used with MongoDB can be connected to DocumentDB without any changes.
  • SQL Queries: Although DocumentDB is a non-relational data store, it supports SQL, so developers already familiar with database such as MySQL, Postgres, and SQL Server can get up and running quickly. Since DocumentDB is non-relational, some SQL features such as joins work differently than developers might expect.

Limitations:

  • Price: at 25 cents per gigabyte, it is significantly cheaper than Azure SQL. Storing 2TB of data on DocumentDB would cost $500 per month; a 2TB SQL Azure Elastic Database would cost about $4400 per month.
  • Scaling: While DocumentDB can scale to hold a large amount of data, document collections that will need to scale easily have to be created as partitioned collections from the beginning. Having said that, scaling DocumentDB is easier and cheaper than scaling Azure SQL Database. At the time of writing, the largest available SQL Azure Database offers 2.9TB of storage and costs over $6,000 per month.

SQL Azure Database

Benefits:

  • SQL Server familiarity. SQL is a nearly feature complete version of SQL Server, so most of your favourite T-SQL commands and tools such as SQL Server Management Studio will work.
  • Azure SQL is a relational database, which makes it a great fit for most business data. You have defined tables and schemas, along with foreign keys, triggers, and all of the other features you’ve come to expect from a relational database.
  • Data Integrity – Since you’re able to ridigly define schemas and relationships between tables, you can make it difficult or impossible for bad data to get into an Azure SQL Database. With Azure DocumentDB, most data integrity checks must be done at the application level, and it’s easy to make mistakes when using this approach.
  • Flexible pricing and availability. Spinning up a small Azure SQL Database instance is much cheaper than buying a SQL Server license. At the high end, it’s possible to automatically replicate elastic Azure SQL Databases across geographic regions, assuming you have deep pockets.

Limitations:

  • Cost – as mentioned above, Azure SQL Databases are much more expensive than DocumentDB collections. With DocumentDB, you pay for the storage you use. With Azure SQL, you have to create a database instance, and each instance type has a hard cap on the amount of data it can store.
  • Scalability – This is a familiar concern for scalability of relational vs NoSQL-style datastores everywhere, not just on Azure. NoSQL databases tend to be easier to scale out, because it’s easier to partition collections and split them across machines. With relational databases like Azure SQL, scaling up as far as possible is your best option. As mentioned in the DocumentDB section, scaling up an Azure SQL Database can become very expensive very quickly.

Conclusion

Azure DocumentDB and Azure SQL Database are both great choices when building a complex application. Which one is right for you depends on the needs and constraints of your application – and probably on the constraints of your budget.

Azure DocumentDB vs Azure Table Storage

Questions about the differences between Azure DocumentDB and Azure Table Storage are asked quite often at Stack Overflow and various other Q&A sites. This short article will explain the differences and describe why you might want to choose one over the other.

If you’re looking for a comparison between Azure DocumentDB and Azure SQL Database, you can find it here.

Executive Summary

If you’re in a hurry and just want the conclusion, here it is: Azure DocumentDB is more capable than Azure Table Storage, but is also more expensive. You can save a significant amount of money by choosing Table Storage if it meets your needs. Read on to learn more.

Azure Table Storage

Azure Table Storage is a distributed, high performance NoSQL key-value store.

Benefits:

  • All commits are automatically replicatied – 3 times in one geographic region, and 3 times in another. This ensures that data will still be available even if an entire datacenter goes dark.
  • Strong consistency – once data has been added or updated, all future accesses of that data will see the updated version. In contrast, some other NoSQL data stores only offer eventual consistency. In these cases, reads are not guaranteed to see the most recent updates.
  • Flexible schema – like other NoSQL data stores, Azure Tables does not require a fixed schema to be defined up front.
  • Can easily scale to store billions of entities while still providing good performance.
  • Affordable – prices range from 4.5 to 12 cents per gigabyte.

Limitations:

  • Each table contains only two indexed columns: a partition key and a row key. This means that you can only run queries based on these keys. You can’t index any columns or properties of the rows you insert, and so can’t run queries against them. This isn’t always a deal breaker – it just means that Table Storage will be a good fit for some use cases, but not for others.

Tutorial:

Azure DocumentDB

DocumentDB is a relatively new addition to the Azure family. It was introduced in August of 2014. It is a distributed document database. It can be used in scenarios where other document stores such as MongoDB would be a good fit.

Benefits:

  • Documents are stored in JSON format, which makes them very easy to work with in a wide variety of programming languages.
  • Offers a range of consistency levels, ranging from strong consistency to eventual consistency. This makes it possible to adjust consistency to suit your application’s needs.
  • MongoDB protocol support: Applications designed to be used with MongoDB can be connected to DocumentDB without any changes.
  • SQL Queries: Although DocumentDB is a non-relational data store, it supports SQL, so developers already familiar with database such as MySQL, Postgres, and SQL Server can get up and running quickly. Since DocumentDB is non-relational, some SQL features such as joins work differently than developers might expect.

Limitations:

  • Price: at 25 cents per gigabyte, it is more than double the cost of Azure Tables’ most expensive rate.
  • Scaling: While DocumentDB can scale to hold a large amount of data, document collections that will need to scale easily have to be created as partitioned collections from the beginning.

Conclusion

It comes down to choosing the data store that best meets your needs.

On Azure, Table Storage is inexpensive and easy to scale.

DocumentDB is more expensive and somewhat more difficult to scale, but offers a much richer feature set and query language.

Also worth mentioning is the Azure SQL Database. With excellent SQL Server compatibility, it offers the ability to easily migrate existing enterprise applications to the cloud. It’s more expensive and more difficult to scale than either Table Storage or DocumentDB, but offers rock solid reliability along with the full power of SQL and a relational database.

Connected vehicle services favor Azure hosting

Interesting Azure news shared by Digital Trends today. It seems that many automotive manufacturers are planning to use Azure to host the backends for their AI and Augmented Reality services.

With the trend toward increased vehicle automation and eventually full self-driving vehicles, this could represent a very nice foothold for Azure in a sector that is likely to grow rapidly in the next 5 years.

From the article:

Showcased for the first time at CES 2017, Microsoft’s Azure is going to help power artificial intelligence (AI) bots which will augment driving by providing additional safety warnings, detecting driver engagement, and personalizing the driving experience. Microsoft’s cloud bots will be able to customize the ride, performance and entertainment options depending on who is driving.

But Microsoft’s services don’t just bolster the company’s own services, they will also act as a foundation for a number of third-party software providers. British automotive engineering firm IAV has developed new automated vehicle technology that will use Azure processing and storage to make vehicles more aware of their surroundings and integrate with a number of public space technologies to enable vehicles to better understand their environment.

Mapping software company Esri is much the same. It utilizes Azure to handle geographic data and analytics to better understand the driver behind the wheel, whether they are an AI or a human. By being able to better predict how vehicles will react, it can offer more information to whoever is in control, thereby improving road safety and efficiency.

Insurer Swiss Re is also looking to use Microsoft’s Azure to handle telematics which can give it better insight into driver behavior and therefore offer much more specialized insurance packages for consumers.

The complex relationship between drivers — AI and human — and the technology that is being added to smart, connected vehicles, requires a robust platform and Microsoft’s Azure is proving popular with a number of technology developers. It’s going to be interesting to see if one or two dominant platforms end up taking over the connected car scene, or whether the marketplace will have a lot of key players, like the automotive industry itself.

Read the full article here.

Azuze Stack GA Coming Mid-2017

Interesting news on the Azure blog today: Microsoft’s on-premise version of Azure, a.k.a Azure stack, will be generally available in mid 2017. Initially, it will only be available bundled with hardware in turnkey integrated systems from Dell, HP, and Lenovo.

From the blog:

Customers should use Azure services to develop their apps today. Since Azure Stack and Azure share a unified application model with API consistency, these efforts will accrue to Azure Stack at general availability

A single node experience, like the one delivered in Azure Stack TP1, will be available with subsequent Technical previews and general availability for customers to quickly experience, learn and develop against Azure Stack. The next technical preview will be available later this year.

Customers ready to deploy an Azure-consistent cloud on their premises now should buy Microsoft Cloud Platform Solution (CPS). Customers will be able to use Azure Stack to manage CPS resources thereby preserving investments in CPS.Customers should also check out Windows Server 2016 and deploy Hyper-V as that is the host virtualization technology used in Azure Stack.

Read more on the Azure blog site.

Git Deploying a Basic PHP App to Azure

Introduction

In this tutorial, we’ll be creating the simplest possible PHP app, and then deploying it to the Azure App Service using Git.  Although there are already several PHP-on-Azure tutorials online, many of them are either overly complex, or outdated.

Prerequisites

You’ll only need a few things:

  • An Azure account; free and trial accounts will be fine for this exercise. If you don’t have an Azure account yet, go and create a free account before proceeding.
  • Git must be installed on your machine.
  • You should be comfortable using the command line.




Getting Started

Begin by signing in to the Azure admin portal. Once you have done this, you’ll see this menu:

azure-menu

Click on App Services. You’ll then see this screen:

click-add

Next, click on Add to create a new app. When you do, you’ll see this:

app-add

Enter a name for your app. It’ll have to be a name that nobody has yet used on azurewebsites.net. If you don’t see a green check mark, change the name of your app until you’ve found one that is unique.

If you have any existing subscriptions, you can choose between them in the drop-down box. If not, just leave the default setting.

If you have any existing Azure resource groups, you can click ‘Use Existing’ to choose one of them. Otherwise, choose ‘Create New’ and enter a resource group name. Don’t worry if you don’t know what a resource group is – we’ll cover that in a future tutorial.

When you’re done, click the Create button. You will be redirected to the App Services screen. You’ll see several status messages pop up at the top right of your web browser. They’ll look something like this:

deployment

Wait until you see a message telling you that your application is ready to use. When that happens, click the Refresh button:

refresh

When the page refreshes, you should see your new application in the list:

app-running

Click on your application to load its setting screen. It will look like this:

app-settings

Then, click on Application Settings, and you’ll see the following panel:

php-version

Change the PHP version to 7.0. You can leave it set to the default of 5.4 if you prefer, but unless you need to use an older PHP version, I suggest version 7. Click Save when you’ve done this. Next click on Deployment Credentials in the Settings menu. You’ll see the following screen:

set-credentials

Enter a user name and password. Remember these credentials, because you’ll need them to deploy via Git in a few minutes. When you’re done, click Save. When you’ve saved your credentials, click on Deployment Source in the Settings menu. You’ll see this:

deploy-source

Click on Choose Source, and you’ll see this:

deploy-to-git

Next, click Local Git Repository, and then click the Ok button to save your choice. Next, click Properties in the Settings menu. On the right, you’ll see field marked GIT URL. Click on the button beside it to copy it to the clipboard.

git-url

You’re done with the Azure configuration! All that’s left is to create your application and upload it.

Start by opening a command line or terminal window. Navigate to the directory where you’re going to create your Azure PHP app. Create a subdirectory for it by typing the following:

mkdir php-azure-test

Then change into the newly created directory by typing:

cd php-azure-test

Now that we’re in the newly created directory, initialize a git repository by typing:

git init

Next, we’ll add our app’s Azure repository as a Git remote. Type

git remote add azure https://*****@phptest***.scm.azurewebsites.net:443/PhpTest47988.git

but paste in your own repository address after the word azure. It should still be on your clipboard, but if not, go back to the Azure admin panel and copy it again.

Once you’ve added the remote repository, you’re ready to create your ultra-simple PHP app. Using the text editor of your choice, create a file named index.php in your application’s directory and put the following content in it:

<!DOCTYPE html>
<html>
  <head>
    <title>PHP on Azure</title>
  </head>
  <body>
    <h1>Hello from PHP on Azure!</h1>
    <p>
      <?php
        echo 'The date is: ' . date('Y-m-d H:i:s');
      ?>
    <p>
  </body>
</html>

Save the file, and go back to your terminal/command prompt. Type

git add .

and then

git commit -m "initial commit"





At this point, you’re almost done! There’s just one last command to type:

git push azure master

When you hit Enter, Git will ask for your credentials. Use the user name and password you set on the Deployment Credentials screen. Enter these, and Azure will receive your Git push and deploy your site!

To see it in action, just navigate to https://your-site-name.azurewebsites.net, replacing your-site-name with the name you chose for your application. You should see this:

azure-test

And you’re in business! You’ve just deployed your first PHP app to Azure. It doesn’t do much yet, but the hardest part is out of the way. Watch for a future tutorial on adding Azure SQL Database functionality to our test application.

Azure will overtake Amazon AWS for Infrastructure as a Service

An interesting report on a new CIO survey: