In Response to Rep. Mike Rogers (R-Michigan)

Representative Mike Rogers (R-Michigan), chairman of the House Intelligence Committee, said of Guardian reporter Glenn Greenwald, who published secret material leaked by former NSA contractor Edward Snowden that:

“[Greenwald] doesn’t have a clue how this thing works. Neither did the person who released just enough information to be dangerous.”

 

The snippet above was taken from an article by Jane C. Timm (@janestreet) on the MSNBC/Morning Joe blog in which Greenwald defends his own actions, and those of Snowden as "essential to Democracy. 

Really?

Here is what I have to say to Rep. Rogers, and all the rest of our electeds who provide supposed "oversight" in relation to the type of intelligence gathering which involves collection of data from American citizens, on American soil, with no notice, no recourse, and no probable cause:

Please, Mr. Chairman, please do enlighten us, with sufficient information to NOT be dangerous, and so that we, the people YOU WORK FOR, DO have a clue "how it works."

When you are collecting my private communications, I expect you to act with accountability. As a proud American, I am ashamed that those who (somehow) find themselves elected to office anymore seem to think they act with impunity. The safety of our nation is indeed a priority. But there are ways you can get what you need without obliterating our constitutionally guaranteed freedoms and protections.

 

Let the Spin, Begin: Google CEO Larry Page and Facebook CEO Mark Zuckerberg Read from the Same . . . um . . . Script?

In the wake of news reports that the National Security Agency (NSA) has been secretly mining data from large internet service providers Facebook CEO Mark Zuckerberg and Google CEO Larry Page both released statements about their respective company's position on the matter.

While both read like well-thought-out, carefully crafted (but very "corporate") responses, and appear to support the notion that neither company actually participates in a program like the alleged PRISM, both statements also read like thinly disguised paraphrases of the same script. You know, almost like they were being spoon fed.

We've Never Heard of PRISM

---

Both companies also appear to craft their statements using very carefully chosen language. From Zuckerbergs post on Facebook (Emphasis mine):

"Facebook is not and has never been part of any program to give the US or any other government direct access to our servers. We have never received a blanket request or court order from any government agency asking for information or metadata in bulk, like the one Verizon reportedly received. And if we did, we would fight it aggressively. We hadn't even heard of PRISM before yesterday."

And now, From Larry Page's post, released shortly prior to Zuck's statement (again, emphasis mine):

"First, we have not joined any program that would give the U.S. government—or any other government—direct access to our servers. Indeed, the U.S. government does not have direct access or a “back door” to the information stored in our data centers. We had not heard of a program called PRISM until yesterday . . . Until this week’s reports, we had never heard of the broad type of order that Verizon received"

Interesting that in both instances, each CEO is very specific in stating what their company is not doing. They have not granted the government direct access to their servers. They have never received a blanket request such as that reportedly received by Verizon. If you read the full content of each CEO's statement you will find that they are essentially paraphrasing each other, or some third source.

Apple spokesman Steve Dowling also responds with a similar statement:

"We have never heard of PRISM. We do not provide any government agency with direct access to our servers, and any government agency requesting customer data must get a court order."

When asked whether Apple had joined the joint NSA-FBI data collection program, Apple declined to comment, according to the Huffington Post.

Only with a Court Order?

---

All of the companies that have responded publicly make some form of statement indicating that they comply only with court orders, and under applicable law. Each gives some lip-service to resisting attempts by government to compromise the privacy of users. However, in an article from the Washington Post, legal director of the American Civil Liberties Union states:

"I would just push back on the idea that the court has signed off on it, so why worry? This is a court that meets in secret, allows only the government to appear before it, and publishes almost none of its opinions. It has never been an effective check on government."

Bad things are happening on the web. Governments around the world seek to monitor and control this invaluable communications resource. Totalitarian governments like those of China and Iran have set the example for what we, in the US, do not want to see happen.

Except, well, it kind of is happening, and has been for several years now.

I understand that, to paraphrase US President Barack Obama, you can't have 100% security, and 100% freedom, and 100% privacy with zero inconvenience. But the lack of transparency and sheer underhandedness of the US government in this case appears to be not only appalling, but growing by the minute.

It's not the Crime that Kills You, It's the Cover-up

---

We don't know all the facts at this point, and we likely never will. But paying close attention to the manner in which the big internet providers respond is at the very least interesting, and quite possibly a sign that there is, indeed, more here than meets the eye.

I encourage the Googles and Facebooks and Apples of the Silicon Valley to remember the old political adage: It's not the crime that kills you, it's the cover-up.

John on Google

 

Modeling a Directory Structure on Azure Blob Storage

Windows Azure has matured nicely over the past few years into a very developer-friendly "Infrastructure-As-A-Service" platform. While many of the recent public announcements have been focused Azure Websites, Deployment from Source Control, and the new general availability of Azure Virtual Machines, one of the core features of the Azure platform remains storage.

Specifically, Azure Blob Storage.

If you are not familiar with Azure blob storage, visit the Azure site, or check out an overview of what it's all about.

Blobs are Great and All That, but What About Files and Folders?

---

So far as Azure itself is concerned, a blob represents one or blocks of binary data. Much like data on your local hard drive, the notion of directories, files, and the tree-like hierarchal model so familiar to most users is imposed upon the stored data as an abstraction. In the case of your local hard drive, this model is implemented by the operating system.

Within the Windows Azure storage model, there is no OS to impose such structure. Organization and interpretation of the data structure is left up to the client. It is in this way that we are able to store any type of data on the Blob storage platform, and similarly why blob storage is easily consumed by multiple languages and useable from any platform – the structure of the data is platform agnostic.

It's All in the Name

---

The blob storage model and associated APIs establish addressing and naming conventions which serve to identify individual blobs within storage containers. We address blobs via URLs according to the following format:

http://<your-storage-account-name>/blob.core.windows.net/<container-name>/blob-name

In the above, the URL is composed of your Azure Storage Account name, the /blob.core.windows.net/ namespace, followed by the name of the container in which the blob is located, and finally the name of the blob itself. However, as you recall from our overview, blob names can contain any characters, including forward slashes. For example, one could create a blob named Documents/Photos/Graduation Pic.jpg, which, assuming the following details,  would be addressed as follows:

Storage Account: mystorageaccount

Container Name: mycontainer

Blob Name: Documents/Photos/Graduation Pic.jpg

The Blob name above implies that within the container mystorageaccount, there is a directory named Documents, containing a subdirectory named Photos, in which a file named Graduation Pic.jpg is located.

Access this blob using:

http://mystorageaccount/blob.core.windows.net/mycontainer/Documents/Photos/Graduation Pic.jpg

In the Azure storage Account view, a virtual hierarchal directory structure might look like this:

In the image above, note the names of the blobs in the 'Name" column. As far as Azure is concerned, these are simply the blob names. However, much like your operating system, the various SDK implementations afford functionality which can optionally parse these names into a directory structure.

In the above, for example, the blobs File 1.txt, File 2.txt, and File 3.txt can be thought of a being at the root level of the Storage Container, while the blobs named Johns Files/File 1.txt, Johns Files/File 2.txt, and Johns Files/File 3.txt can be thought of as being contained in a directory named Johns Files/. Similarly, We can also see that there is an implied subdirectory within the Johns Files/ directory named Music/, again containing three files.

If we scroll to the right in the Azure browser view above, we see that the same structure is mirrored in the URL for each file, except the file name now conforms to legal URL naming standards:

While Azure storage itself does not recognize the notion of a directory as implied by the delimited blob name, the Azure SDK for your chosen language does, to a certain extent, and assists us in parsing an implied directory structure out of the blob address + name. In this post we will look at the .NET API, however, similar implementations are available for Java, Ruby, Python, and other common platforms.

API Access to the Storage Account and Containers

---

First we will look at some of the basics involved in accessing an Azure storage account and the containers hosted therein. Using the Azure .NET API, we can create a simple Console application which presents required credentials to the Azure storage account, and then retrieves an IEnumerable <CloudBlobContainer> representing the blob storage containers as follows (note that the various other SDKs and APIs define similar functionality for the appropriate platform/language). To do this, we use the ListContainers() method of the CloudBlobClient class:

// in a real project, one might want to implement some security here:
const string ACCOUNT_NAME = "xiv";
const string ACCOUNT_KEY = "myAccountKey";
const string AZURE_CONNECTION_STRING = ""
    + DefaultEndpointsProtocol=https;AccountName={0};AccountKey={1}";
static void Main(string[] args)
{
    var storageAccount = CloudStorageAccount.Parse(string.Format(AZURE_CONNECTION_STRING, 
        ACCOUNT_NAME, ACCOUNT_KEY));
    var client = storageAccount.CreateCloudBlobClient();
    foreach (var container in client.ListContainers())
    {
        Console.WriteLine("Container: " + container.Name);
    }
    // This pauses execution so the console output can be viewed:
    Console.Read();
}

 

In the above, the code simply iterates over the Enumerable and prints the name for each container to the console output. However, the CloudBlobContainer class exposes a variety of useful methods designed to facilitate blob data access. For the purpose of this post, we are primarily interested in the ListBlobs() method.

The ListBlobs method, and the IListBlobItem Interface

---

The ListBlobs() method returns an instance of IEnumerable<IListBlobItem> which is essentially a list of the blobs within the container. However, the enumerable also includes representations of the implied directory structure.

Items returned by the Instance of Enumerable will one of two types, both of which implement the interface IListBlobItem. Actual blob data ("files" so to speak) will be returned as instances of CloudBlockBlob. Directories, which are essentially abstractions created by the API based upon the structure implied by blob names delimited with forward-slashes, are returned as instances of CloudBlobDirectory.

The instances of IListBlobItem returned in the enumerable can be cast to either CloudBlobDirectory or CloudBlockBlob. From there, we can access properties of each in order to print representations to the console window. For example, if we want to focus on directories only, we could add a method as follows, which iterates over the enumerable passed as an argument, checks the underlying type of each IListBlobItem, and if the underlying type is CloudBlobDirectory, prints the directory prefix to the console window. We then employ a little recursion and do the same for each CloudBlobDirectory instance:

Define the printCloudDirectories Method:

static void printCloudDirectories(IEnumerable<IListBlobItem> blobList)
{
    foreach (var blobitem in blobList)
    {
        if (blobitem is CloudBlobDirectory)
        {
            var directory = blobitem as CloudBlobDirectory;
            Console.WriteLine(directory.Prefix);
            printCloudDirectories(directory.ListBlobs());
        }
    }
}

 

Now we can add a line to our Main method as defined in the previous section, and after printing the name of each container, we can pass the output of the ListBlobs() method to our new printCloudDirectories method:

Call printCloudDirectories from Main:

static void Main(string[] args)
{
    var storageAccount = CloudStorageAccount.Parse(string.Format(AZURE_CONNECTION_STRING, 
        ACCOUNT_NAME, ACCOUNT_KEY));
    var client = storageAccount.CreateCloudBlobClient();
    foreach (var container in client.ListContainers())
    {
        Console.WriteLine("Container: " + container.Name);
        // ADD A CALL TO printCloudDirectories:
        Program.printCloudDirectories(container.ListBlobs());
    }
    // This pauses execution so the console output can be viewed:
    Console.Read();
}

 

The output from our little application, if run against the storage account example above, at this point looks like this:

A Simple Console Demonstration

---

Let's take this a few steps further, and create an application which iterates over the containers of a storage account, and writes a text representation of the implied directory structure to the console output.

In our Main method, we will authenticate as before by presenting our credentials. We will then get a reference to an instance of CloudBlobClient. From here, though, we will make a few minor modifications. We define a method named writeAzureDirectoriesToConsole which accepts an argument of IEnumerable<CloudBlobContainer>. Similar to our previous method, this iterates over the Enumerable, and writes the container name to the console output. From here, however, the output of the ListBlobs() method is passed as an argument to a method named getContainerDirectories, which returns a string representation of the file structure we are after.Unlike our previous example, the getContainerDirectories method employs a LINQ query to parse directories and blob files separately, and also adds some rudimentary indentation to the output for readability. The indented formatting also suggests the tree-like structure we associate with a hierarchal data structure:

// in a real project, one might want to implement some security here:
const string ACCOUNT_NAME = "xiv";
const string ACCOUNT_KEY = "MyAccountKey";
const string AZURE_CONNECTION_STRING = ""
    + "DefaultEndpointsProtocol=https;AccountName={0};AccountKey={1}";
static void Main(string[] args)
{
    var storageAccount = 
        CloudStorageAccount.Parse(string.Format(AZURE_CONNECTION_STRING, ACCOUNT_NAME, 
            ACCOUNT_KEY));
    var client = storageAccount.CreateCloudBlobClient();
    writeAzureDirectoriesToConsole(client.ListContainers());
    // This pauses execution so the console output can be viewed:
    Console.Read();
}
static void writeAzureDirectoriesToConsole(IEnumerable<CloudBlobContainer> containers)
{
    foreach (var container in containers)
    {
        string indent = "";
        Console.WriteLine("Container: " + container.Name);
        // Pass Ienumerable to recursive function to get "subdirectories":
        Console.WriteLine(getContainerDirectories(container.ListBlobs(), indent));
    }
}
static string getContainerDirectories(IEnumerable<IListBlobItem> blobList, string indent)
{
    // Indent each item in the output for the current subdirectory:
    indent = indent + "  ";
    StringBuilder sb = new StringBuilder("");
    // First list all the actual FILES within the current blob list. No recursion needed:
    foreach (var item in blobList.Where((blobItem, type) => blobItem is CloudBlockBlob))
    {
        var blobFile = item as CloudBlockBlob;
        sb.AppendLine(indent + blobFile.Name);
    }
    // List all additional subdirectories in the current directory, and call recursively:
    foreach (var item in blobList.Where((blobItem, type) => blobItem is CloudBlobDirectory))
    {
        var directory = item as CloudBlobDirectory;
        sb.AppendLine(indent + directory.Prefix.ToUpper());
        // Call this method recursively to retrieve subdirectories within the current:
        sb.AppendLine(getContainerDirectories(directory.ListBlobs(), indent));
    }
    return sb.ToString();
}

 

As we can see, once we have successfully authenticated using our storage account name and associated account key, we create an instance of CloubBlobClient using the CreateCloudBlobClient() method of our StorageAccount instance. From there, we pass an IEnumerable<CloudBlobContainer> (from the ListContainers() method of our client object) to our hacked-together method writeAzureDirectoriesToConsole.

The writeAzureDirectoriesToConsole method simply iterates over the containers passed in, writes the name of the container to the console (in uppercase) and passes each container reference to the slightly more complex getContainerDirectories method, along with an empty string as an initial indentation level. The indentation will help visually display our directory structure in the console by indenting subdirectories and their contents.

The getContainerDirectories method adds four spaces to the indent parameter passed in, then uses a LINQ query to return an IEnumerable<IListBlobItem> for which the instances of IListBlobItem can all be cast to type CloudBlockBlob. each instance is so cast, and then written to the StringBuilder instance for console output after pre-pending the indent.

Next, we retrieve an IEnumerable<IListBlobItem> for which each instance can be cast to type CloudBlobDirectory. As we have seen, the "directories" obtained this way do not represent actual files, but rather an API interpretation of the blob names. Again, each "directory" prefix is pre-pended with the indentation, and then appended to the StringBuilder for output to the console. However, at this point, the getContainerDirectories method is then called recursively, and passed the IEnumerable<IListBlobItem> returned from the current directory's ListBlobs() method, and the result also appended to the StringBuilder for eventual output.

If we run our example against the cloud storage account pictured above, the console output looks something like this:

Simplify the Structure for Display:

---

We can go a step better here by trimming off the redundant sub-directory paths before we display our tree structure. In the following, I added some lines of code to the  which do just that:

static string getContainerDirectories(IEnumerable<IListBlobItem> blobList, string indent)
{
    // Indent each item in the output for the current subdirectory:
    indent = indent + "  ";
    StringBuilder sb = new StringBuilder("");
    // First list all the actual files within the current blob list. No recursion needed:
    foreach (var item in blobList.Where((blobItem, type) => blobItem is CloudBlockBlob))
    {
        var blobFile = item as CloudBlockBlob;
        // If the current blob item is at the root of a container, there
        // will be no parent directory. Use the file name as-is:
        string outputFileName = blobFile.Name;
        // Otherwise, remove the parent directory prefix from the displayed name:
        if (blobFile.Parent != null)
        {
            outputFileName = blobFile.Name.Replace(blobFile.Parent.Prefix, "");
        }
        // append to the output:
        sb.AppendLine(indent + outputFileName);
    }
    // List all additional subdirectories in the current directory, and call recursively:
    foreach (var item in blobList.Where((blobItem, type) => blobItem is CloudBlobDirectory))
    {
        var directory = item as CloudBlobDirectory;
        string directoryName = directory.Prefix;
        if(directory.Parent != null)
        {
            directoryName = directoryName.Replace(directory.Parent.Prefix, "");
        }
        sb.AppendLine(indent + directoryName.ToUpper());
        // Call this method recursively to retrieve subdirectories within the current:
        sb.AppendLine(getContainerDirectories(directory.ListBlobs(), indent));
    }
    return sb.ToString();
}

 

In the code above, we have simply added some logic to replace the parent directory prefix in the displayed names of subdirectories, using the Parent property of both CloudBlobDirectory and CloudBlockBlob. In both cases, the parent property returns the CloudBlobDirectory which is the parent of the current item. If there is no parent (in other words, if the current item is at the container root level) then the Parent property will return null, so we need to test for this.

After making the above modifications, when we run our code now the console output is a little more readable:

But . . . What Good Is It?

---

So far, we have taken a very cursory look at the manner in which Windows Azure allows us to impose a directory structure on our blob storage. We can see how we might expand upon these and other aspects of the blob storage API to create a fairly advanced file management application (for example, a desktop or web client) to facilitate management of data, and/or create a stand-alone "cloud drive" type service. As an example, the screenshot below is an early version of a desktop client I am putting together for an upcoming post. Note that it is currently pointed at the same Azure storage account as our console example. Look for this in an upcoming post.

Example of a More Developed Use Case:

---

The various APIs/SDKs offer a host of properties and methods allowing us to take advantage of Azure Blob Storage features. With the ever-growing cloud-based nature of our daily computer usage, and the nearly ubiquitous, pervasive presence of the internet in our daily lives, the ability for our applications to integrate with scalable, high-availability storage is not going away soon. Services such as Windows Azure, Amazon Web S3, and other API-based cloud storage services will become more and more important in our application architectures.

I will be exploring this topic further in the near future. I hope to shortly have a post discussing implementation of a very basic desktop client application similar to that pictured above. Additionally, I hope to have a similar example of a web-based client which implements at least some basic but effective authorization.

Additional Resources:

---

• Azure Developer Center (SDK's/API's Documentation)
• Understanding Windows Azure Blob Storage (A Quick Overview)
• Deploying an Azure Website from Source Control
• Developing Cloud Applications with Windows Azure Storage

John on Google CodeProject

 

Understanding Windows Azure Blob Storage (A Quick Overview)

In the course of the past two years Microsoft has made significant strides in creating a developer-friendly experience for using Windows Azure. From a rather disjointed (and to me, poorly understood) beginning, Windows Azure has grown into a fascinating playground for those of us wanting to explore aspects of "Infrastructure-As-A-Service" (IAAS).

At the time of this writing there has been a lot of attention focused upon such sexiness as  deploying websites to Azure from integrated source control, and integration of Azure with Microsoft's Webmatrix platform. However, cloud storage is one of the core elements of Azure's IAAS offerings, and will likely play a role in any other Azure services you use.

Azure Blob storage, like Amazon S3, offers a handy (and cheap) way to persist content and make it available across the web. For example, there was a minor kerfluffle last year when Github decided to eliminate the "Downloads" feature of their project hosting platform. Services such as Amazon S3 or Azure Blob Storage present an alternative location to host project binary files and/or other resources for easy linking and download.

Or, if you're like me, you might just find it fun (and informative) to experiment with modeling up your own cloud-based storage client for whatever purpose. On the whole, storage such as provided by Amazon or Azure is incredibly cheap, and it is possible to store a boatload of files for pennies each month (literally).

• What's a Blob?
• Azure Blob Storage Model – Overview
• Block Blob Specifics
• Blob and Container Naming Requirements
• Blob URLs, Supported Languages, and API Access

What Can it Do for Me?

---

According to the Azure Website, Azure Blob Storage is " . . . a service for storing large amounts of unstructured data that can be accessed from anywhere in the world via HTTP or HTTPS." From the same site, common uses for Azure Blob storage might include (but are definitely no limited to):

• Serving images or documents directly to a browser
• Storing files for distributed access
• Streaming video and audio
• Performing secure backup and disaster recovery
• Storing data for analysis by an on-premises or Windows Azure-hosted service

While the Azure team appears to place the focus on "large amounts of unstructured data," blob storage is equally useful for storing data of any size. As previously mentioned, it is possible to create a basic "cloud drive" type application using Azure storage, or Amazon S3 (I believe Dropbox uses Amazon as its backend).

What's a Blob?

In the most general sense, the term "blob" is commonly understood to mean "Binary Large OBject." Many of us are familiar with this term from its usage in database-land, where "blob data" might be data stored in our database which does not conform to an established data type as defined by the database. Such data are usually (if the database supports it) persisted as plain binary data (image files come to mind as an example). 

Most of the major players in the "cloud" storage space have extended this notion to various generic storage implementations which allow client data of any sort to be uploaded/persisted on the vendor storage server in binary format. Amazon S3 implements a model in which binary data ("Objects") are persisted in "Buckets." Windows Azure persists binary data ("Blobs") in "Containers."

Of course, there is more to it than that, and that's what I am discussing in this post.

The Azure Blob Storage Model: Overview

An Azure Storage Account will consist of one or more Containers, which are created and named by the user to hold Blobs. All blobs must be located in a container. In general (and at the time of this writing), an Azure user can have up to five separate storage accounts.

An individual storage account may contain an unlimited number of containers, and an individual container may hold an unlimited number of blobs. However, the total size of all containers may not exceed 100TB. Windows Azure defines two distinct types of blob – Block Blobs and Page Blobs. For the moment, I am going to focus on Block Blobs.

Block Blobs

According to the Azure team, the most common use-cases for blob storage will involve Block Blobs. Block blobs represent binary data that has been segmented into one or more blocks to enable ease of transmission over a network, and sensible management of large data files. The blocks which make up a blob may be of different sizes, up to 4 MB each. Each block within a blob is identified by a Block ID, and may optionally also include an MD5 hash of the blob content. The maximum size for a block blob is 200 GB, and a blob can consist of up to 50,000 individual blocks.

The idea here is that a large file may be broken up into blocks, which then may be uploaded or downloaded separately, in any sequence (and importantly, asynchronously) and then re-associated with each other, in the proper sequence. The blocks which make up a blob are associated with that specific blob through a list enumerating all the blocks within the blob.

When blocks are uploaded, they are associated with the designated blob, but do not formally become part of the blob until the blocks are Committed, by supplying the list of blocks. Each block identified in the list by its Block ID is formally made a part of the blob. Blocks which are uploaded but not formally committed remain uncommitted, and are discarded after one week. Uncommitted blocks may be committed at any point prior to being discarded. When a client attempts to write a block for a blob that does not exist, a new blob will be created. 

Blob data can be modified at the block level. That is, individual blocks can be added to an existing blob, existing blocks can be overwritten or replaced, and specific blocks within a blob can be deleted.

Individual blocks are identified by a Block ID property, which are represented by strings of equal length. The MS Azure site indicates that most blob storage clients utilize base-64 encoding to create ID strings of equal length. Id's must be unique within each blob, but do not need to be unique between different blobs. In other words, blocks in two different blobs may have the same block ID.

Block blob storage is designed to facilitate efficient network file handling and asynchronous file transfer. While the previous may seem a little complex, the Azure team has created API's for a number of popular development languages which make much of this easier to deal with for common use cases.

 

Blob and Container Naming Requirements

Container Names must begin with a letter or a number, can contain only letters, numbers, and the dash (-) symbol, and letters must be all lowercase. Container names must be a minimum of 3 and not more than 63 characters in length.

Blob Names can contain any characters, but special characters and characters reserved for use in URLs must be escaped. Blob names can include upper and lower-case letters, and cannot exceed 1024 characters in length.

Container names and blob names are combined to form part of the URL by which the blob is accessed, so names for each must conform to DNS naming standards when combined.

Blob URLs and API Access

Blobs are accessible through URLs in the following format:

http://<your-storage-account-name>/blob.core.windows.net/<container-name>/blob-name

The Azure team has created a number of SDKs/APIs for programmatically working with blob storage. As of this writing, the following languages/platforms are supported with SDKs/APIs which expose various Azure services, including Blob Storage:

• .NET SDK / .NET API Reference
• Java SDK (Windows) | (Mac) | Linux / Java API Reference
• PHP SDK
• node.js SDK (on Github)
• Ruby SDK | Windows | Mac | Linux
• Python SDK

In addition, Azure defines a REST API for all storage services useable by any application which can send/receive HTTP or HTTPS requests/responses. Some of the SDKs above rely on the Rest API for programmatic access.

Additional Resources

• Azure Developer Center (SDK's/API's Documentation)
• Modeling a Directory Structure on Azure Blob Storage
• Deploying an Azure Website from Source Control
• Developing Cloud Applications with Windows Azure Storage

John on Google CodeProject

 

The Best Things in Life Are Free . . . If We Take the Time to Notice . . .

John, Step Away from the Code Editor!

I am a died-in-the-wool nerd. I love my computers, and I love learning to code. Left to my own devices, I will spend the better part of the day and night chopping away at the keyboard, trying to make something cool, or at least something that doesn’t suck. In this, there is danger, though.

Like most (I think) people who tend towards technical pursuits, I have an almost ADD addiction to the work/suffer/reward cycle that comes from busting my ass trying to get the machine to do what I want. Note, I say "do what I want," because, as we know, the machine ALWAYS does exactly "what I say" to do, but that is not always what I "want."

It is so easy for me to get up on a Saturday morning, crack open the internet and the code editor, and before I know it, it's dark outside, and Saturday is gone. Then, do the same thing Sunday, and then start the work week again. I learn a lot. I "get things done" at work. I meet deadlines, and have experienced some modest professional success.

. . . learn to take some time each day to recognize how precious are the moments we have on this planet, and to appreciate that, for one more day, I woke up this morning and drew breath. For one more day, I have received the gift of being allowed to experience this world, and everything it has to offer.

What is it all Worth, Really?

When all is said and done, though, what is all that really worth? When I leave this planet, I can't take any of it with me. The code we write is a nebulous, ephemeral thing which, at best, will be obsolete in a few years. Make no mistake – I recognize the importance of achievement, of securing financial stability for myself and those I care about, and to some degree, attaining sufficient material wealth to live comfortably and with minimal anxiety. But beyond that, what really matters?

. . . the most important things in life are the experiences we have . . . if you do it right, the most important stuff, in this context, is free . . .

About a decade ago, I was forced to take a long, hard look at the way I lived my life, and to begin a long, slow process of realizing what matters, and what doesn't. The story behind that turning point in my life is outside the scope of this blog. But starting then, I learned to take some time each day to recognize how precious are the moments we have on this planet, and to appreciate that, for one more day, I woke up this morning and drew breath. For one more day, I have received the gift of being allowed to experience this world, and everything it has to offer.

Most importantly, to recognize that the most important things in life are the experiences we have, and that if you do it right, the most important stuff, in this context, is free. If we remember to go take it.

 

A walk through the neighborhood on a warm spring evening . . .

---

There is nothing like the rebirth of Spring, the smells in the air, and the temperate breeze. Often, we get in such a hurry, we forget to get out and ambulate through our environment, our neighborhood, the place we live.

Each evening, I try to get out and walk, and while walking, remain hyper-aware of the everyday, commonplace things around me that I might otherwise take for granted, or miss entirely.

 

 

 

The number of times one gets to experience Spring in this life is finite. Try not to miss the little things.

 

Teaching Someone how to Play the Guitar . . . or do it Yourself, Live . . .

---

"Music, whether played yourself or absorbed through active listening, has the power to change your psychic state . . ."

All of my life, music has held sway over me. My mother likes to tell the story of me at age 3, sitting on the floor next to the old turntable with my ear pressed against the speaker, listening intently to the massive snare and cello at the end of the Simon and Garfunkel classic "The Boxer." In my early teens, I learned to play the guitar, and since then, music has been my solace, passion, and escape. In my twenties, I found the sheer, addicting exhilaration of playing, at high volume, to large appreciative audiences. There is truly nothing like it.

Now, in middle age, I find the utmost reward in teaching the step-children to play, and in passing well-loved and well-played instruments on to a new generation. My much-loved black Fender Stratocaster (seen in the hands of the youngest step-child, above) was handed down last year (to the same step daughter. No worries – I replaced it with a new pearl white one!).

Music, whether played yourself or absorbed through active listening, has the power to change your psychic state. Passing that passion on to another, and sharing the impact music can have on your life is priceless.

 

. . . The Exhilaration of the Breeze off the Pacific Ocean

---

"Standing on the Westernmost edge of the American continent, gazing out across the largest ocean in the world, it is easy to remember how small we really are in the big scheme of things . . ."

 

 

 

 

 

 

 

 

 

I have been to three coasts in my lifetime (so far), but none creates for me the same sense of peace as the Northwest Pacific Coast. Standing on the Westernmost edge of the American continent, gazing out across the largest ocean in the world, it is easy to remember how small we really are in the big scheme of things. Important to keep in mind, as it is so very easy to mentally overstate our own importance, and the seeming importance of the petty events which make up our daily lives.

Of course, it's also a great place to spend time with friends and family.

Do you have a sea coast? A place where you can feel small, and recognize that is the way it is supposed to be?

Fall at Concordia Seminary in the St. Louis Suburbs . . .

---

Fall is a universal season. But growing up in the American Pacific Northwest, I had never experienced the exceptional explosion of color such as I saw when I moved to St. Louis, Missouri.

The days remained temperate (sometimes, even warm), but a chill was in the air as the deciduous trees on the grounds of Concordia Seminary here in Clayton (a suburb, in a way, of St. Louis) performed their annual magic show.

 

It was at this point I recognized that, while Portland, Oregon, will always be "home," there is a natural beauty to every part of the world. It's all a matter of looking from the right perspective.

Here in the middle of the country, I feel far from my home, friends, and family. But I get to experience the fall in a way I never have before.

And that's a treat.

 

. . . A Sunset at the Gulf Coast of Alabama in Mid-August . . .

---

In the Summer of 2012, I was afforded the opportunity to visit the Gulf Coast of Alabama for a week. After a fascinating drive through the deepest parts of Mississippi, we arrived. The Gulf is unlike the Pacific beaches back home. The heat and near-tropical humidity gave an entirely different feel. The oil rigs operating offshore added a synthetic enhancement to the skyline. And as the sun sets through the moist, humid southern air, the sky takes on a fascinating palette of pastel colors, while a warm breeze picks up.

 

The culture along the gulf coast, while definitely American, also had its own flavor. And you haven't had gumbo until you've had it prepared at a mom-and-pop restaurant here in the place of its origin.

 

The Monuments We make . . .

---

For me, just as it is important to remember how small mankind is in the big scheme of things, it is equally important to remember that we are capable of great victories, despite the laws of nature, and despite seemingly impossible odds.

How DOES one construct a 600 + foot high catenary arch of stainless steel?

While the monuments our species has created over the millennia might be seen as a grand delusion of our own self-importance, they can also serve to remind us as individuals that we are part of a greater whole, That whole, small though it may be on the universal scale of things, is greater than the sum of its parts, and capable of great things.

We all leave this planet with exactly what we brought into it – nothing, and alone. But when the last of us is gone, there will remain, for a time, some evidence we were here, and that we conquered some of the most basic forces of nature and subjugated them to our will, more so than any creature which inhabited this planet before us.

 

 

The People in our Life

---

It’s really easy to get caught up in the frantic here and now, in chasing professional success, material or monetary gain, or other ephemeral "things." I doubt anyone has ever said, on their deathbed, "If only I had worked more".

No one will ever accuse me of being a "people person." However, as I grow older, I find that the people in my life, from various times and places, have made it what it is today.

Studies of how people experience happiness have shown that, while acquiring shiny new things provides a transitory jolt of seeming satisfaction, it is not lasting, and the individual moves on to seek the next thing. On the other hand, shared experiences, such as camping with friends, vacations with family, and some of the things I describe throughout this post are the type of thing which create lasting memories, and ultimately, a full life.

To quote something I found on the inter-webs recently, Life is a one-time offer. Best get it right. TO me that means making the most of the time we have with the people in our lives. Often, the people in our lives are complete strangers whom we have not taken the opportunity to know better yet.

When you leave this world, would the story of your life make a great movie? To quote the philosopher Morrison:

“Is everybody in? Is everybody in? Is everybody in? The ceremony is about to begin. The entertainment for this evening is not new, you've seen this entertainment through and through you have seen your birth, your life, your death....you may recall all the rest. Did you have a good world when you died? -enough to base a movie on??”

- Jim Morrison, An American Prayer

John on Google