I was a big fan of the folk-rock duo The Indigo Girls during the 1990s (arguably their most creative period), but Tuesday evening at Cahn Auditorium in Evanston was the first time I saw them in concert, and it was as good as I hoped.

Amy Ray and Emily Saliers have been recording and touring all these years and have built an impressive catalog of music to share with us. Their concert mixed newer songs and fan favourites. I especially appreciated early classics like "Closer to Fine", "Galileo", and "Power of Two". I was disappointed not to hear some of my personal favourites, such as "Least Complicated" and their cover of "I Don't Wanna Talke About It", but I was not unsatisfied with their selection.
 
The Georgia natives met in elementary school, began playing together in high school, and formed The Indigo Girls in college. Decades later, they still sound good. Amy has always boasted the deeper, rougher voice, while Emily's was higher and gentler. Amy's vocal cords remain strong, while Emily has lost some range over the years, but it is when they harmonize that they sound their best. The two alternate singing lead and when they harmonize it is sometimes together and sometimes with one singing a countermelody to complement the main melody sung by her partner. Both work well, but they execute the melody/countermelody thing to perfection. They sound like friends who have been playing together for decades.

Ray and Saliers have long been advocates of the rights of women, LGBTQ, and other unrepresented groups and their audience reflected this support. The crowd was easily 75% female and many sported clothing with activist messages. Recent events in the US brought a more specific meaning to some of their songs and more passion from the crowd as they sang along. The band did not preach, but they let us know they are on our side.

The two were joined onstage by violinist Lyris Hung, who brought both talent and energy to her performance; and by Lucy Wainwright Roche, who also served as the warmup act, charming the audience with self-deprecating stories between songs. No drummer performed with the band, and she was not missed. The guitars provided all the rhythm necessary.

It was an unforgettable evening.

My Photos of The Indigo Girls

My Photos of Lucy Wainwright Roche

A container allows us to virtualize applications and data and host this on top of a host virtual machine.

Containers provide the following advantages:

• It allows one VM to host multiple containers, potentially providing more efficient use of resources.
• It allows us to isolate the applications in different containers, so they will not interfere with one another.
• Containers allow us to split up an application physically, so that we can deploy, update, and scale each part of the application independently.

Docker is a tool designed to manage containers.

A container is based on an image. An image contains all the information to create a container in the same way that a class contains the information to instantiate an object and a blueprint contains the information to construct a building.

So, before you create a container, you must create an image and tell it what components will be in the container.

The steps are:

1. Create the application source code and/or data in a folder and (optionally) its subfolders
2. Create a Dockerfile that describes what goes into the image/container and what to do with it
3. Use Docker to build the files into an Image
4. Push the Image to a Registry
5. Create and run a container based on that image

Setup

Before you begin, you must install Docker. A simple way to do this is to install Docker Desktop, which you can download here.

You will also need an account at an online registry, such as Docker Hub or Azure Container Service. In this article, I use Docker Hub.

Once you have everything installed and set up, we can walk through the steps listed above.

Create an Application

I created a simple node.js application, consisting of only a single file: app.js with the following code:

var http = require('http');

    var portNumber = 8081;

    http.createServer(function (req, res) {
    
    res.writeHead(200, {'Content-Type': 'text/html'});
    
    res.write('<h1>Hello World!</h1>');
    
    res.write('The time is ' + new Date());
    
    res.write("<h2>Count to 5</h2>");
    
    res.write('<ul>');
    
    for (var i = 1; i <=5 ; i++) {
    
      res.write('<li>' + i);
    
    }
    
    res.write('</ul>');
    
    res.write('<p>Done!</p>');
    
    res.end();
    
    }).listen(portNumber);
    
    console.log('Server running at http://localhost:' + portNumber);
    

This simply outputs some HTML on port 8081. When run, it will display some text, the current date/time, and a list of numbers.

Dockerfile

In the same folder, I created a file named "Dockerfile" (with no extension)

Dockerfile supports many instructions, but I have kept this one simple, as shown below:

FROM node:current-alpine
LABEL author="David Giard"
WORKDIR /src/app
COPY . /src/app
ENTRYPOINT ["node", "app.js"]

FROM tells Docker which image to begin with. The node:current-alpine is a Linux container with the latest version of alpine node installed. You can find a list of pre-built images at https://hub.docker.com/search 

LABEL is optional. We use it to add metadata to our image, as a name/value pair. Adding the author is common.

WORKDIR tells Docker to set the current working folder in the container.

COPY tells Docker to copy files from a folder on my location machine to a folder in the container. The first "." represents the current folder and the second "." represents the working directory in the container, so my command tells Docker to copy all files in the current folder (where Dockerfile is located) to the working folder.

ENTRYPOINT is a command or executable to run to start the container, along with any arguments, separated by commas.

["node", "app.js"]

You can read all about the tags in Dockerfile here.

Build an Image

We build an image from the files in the current folder with the following command:

docker image build -t image_name .

where image_name consists of three parts: the Docker registry name, the Docker repository name, and a tag (which is often used to define the version), using the following format:

registry_name/repository_name:tag

I have a registry on DockerHub named "dgiard", so I can use an image name like the one below to identify version 1.0 an image in my registry in a repository named "myapp":

dgiard/myapp:1.0

The following command creates an image named dgiard/myapp:1.0 (registry=dgiard; repository=myapp; tag=1.0)

docker image build -t dgiard/myapp:1.0 .

Push Image to Registry

After creating an image, we can push it to a registry with the following command:

docker image push image_name

Of course, we need write permission in the registry before we can push an image to it. If we are using DockerHub, we may need to log in first.

Create and run Container

Once it is in the registry, we can run it from any computer with access to the registry via the following command:

docker container run -d --name application_name –p local_port:port_in_container image_name

where:

•      application_name is a name by which you want to identify this application
•      local_port:port_in_container maps a port on the local computer with a port inside the container.
•      image_name is the name assigned to the image when we built it.

Our sample app runs on port 8081, but we can map local port 8000 to 8081 in the container with the clause -p 8000:8081.

In our example above, the command to run a container locally becomes:

docker container run -d --name app1 -p 8000:8081  dgiard/myapp:1.0

We can test our app by opening a browser and entering the following in an address bar:

http://localhost:8000

This should run the application, as shown in Fig. 1.

Fig. 1

Conclusion

This article showed how to create a Docker image; then, build, push, and run a container based on that image.

Here are the key Docker commands we executed for our example:

docker build -t dgiard/myapp:1.0 .

docker image push dgiard/app1:v1 

docker container run -d --name app1 -p 8000:8081  dgiard/myapp:1.0

A container allows us to virtualize applications and data and host this on top of a host virtual machine.

Containers are similar to Virtual Machines in that they virtualize some of your application. the difference is that a Virtual Machine abstracts away the hardware because it sits on top of a Virtual Machine so it abstracts away the operating system. Just as one physical machine can host multiple Virtual Machines, one Virtual Machine can host multiple containers.

Containers provide the following advantages:

• They allow one VM to host multiple containers, potentially providing more efficient use of resources.
• They allow us to isolate the applications in different containers, so they will not interfere with one another.
• Containers allow us to split up an application physically, so that we can deploy, update, and scale each part of the application independently.

A container is based on an image. An image contains all the information to create a container in the same way that a class contains the information to instantiate an object and a blueprint contains the information to construct a building.

Docker is a tool designed to manage containers.

A simple way to install Docker locally is to install Docker Desktop, which you can download here for Windows, Mac, or Linux.

To share images with other users, other computers, or remote platforms (e.g., cloud providers), you need to publish them to a repository. Docker Hub allows you to create repositories. You can create a free account on Docker Hub and create one or more repositories within that account. A repository contains images and containers that you can share. Often all the images in a given repository are related; for example, you may publish images with different versions of the same software and store them all in one repository.

Docker provides some repositories and images that you can use for free. You can use these to learn how to use Docker. For example, you can open a command prompt and type the following:

docker run –d –p 3000:80 docker/getting-started

This will create and run a container hosted in the “getting-started” repository of the “docker” registry. This is a sample container that contains a web application that runs on port 80. Let’s walk through the parts of the above command.

docker run tells Docker to download the container and run it.

docker/getting-started tells Docker where to find the container. In this case it is in the “docker” registry and in the “getting-started” repository.

-d tells Docker to run this container in “detached” mode. This means that Docker will run it asynchronously and immediately return you to the command prompt. Alternatively, you can run the container in “interactive” mode using the –it switch. This will change your command prompt and place you inside the container, rather than your host machine.

-p 3000:80 is used for port mapping. The web application inside the container runs on port 80. We need to tell Docker which port to expose on the local machine to access that port. In this example, we are mapping the local machine’s port 3000 to port 80 in the container.

The output after running the above command is shown in Fig. 1.

Fig. 1

After you run the command, you can view all running containers using the command docker container ls, as shown in Fig. 2.

Fig. 2

After successfully executing the docker run command, we can view the container’s web application in a browser on our local machine by navigating to http://localhost:3000. This should render the container’s web app, as shown below.

Fig. 3

In this article, I explained the fundamentals of images, containers, and Docker; and showed some basic Docker commands.

In the next article, I will show you how to create your own image and publish it to a repository.

The Microsoft Word Spelling and Grammar checker is an impressive tool that has saved me from embarrassment many times.

But, there are times when it gets in the way.

For example, I often write articles that include code samples. I do not want to check spelling in my code because it includes key words and variable names that are not part of the English language.

Microsoft Word includes a feature that allows me to continue using Spellcheck on the document, while suppressing it for sections of text that I identify.

In Fig. 1  is a section of a Word document I recently wrote for a technical article. I want Word to check most of the document, but not the code (the part that begins with ".create-or-alter" and ends with "tostring(location);}")

Fig. 1

To exclude this section from the Spellcheck, I first highlight, as shown in Fig. 2.

Fig. 2

With the text highlighted, I select the [Language] dropdown on the "Review" ribbon and click "Set Proofing Language", as shown in Fig. 3.

Fig. 3

The "Language" dialog displays, as shown in Fig. 4.

Fig. 4

Click the "Do not check spelling or grammar" checkbox and click the [OK] button to close the dialog.

You can repeat this for multiple sections in your document.

The next time you run Spellchecker (Fig. 5), this section(s) will be ignored.

Fig. 5

This is a simple process that can make checking your documents more efficient.

Episode 710

Adi Polak on LakeFS

Adi Polak is the VP of Developer Experience at Treeverse.

She describes how data scientists and developers can use LakeFS to manage Data Lakes, using tools familiar with git developers.

Links:
https://lakefs.io/
https://github.com/treeverse/lakeFS
https://www.linkedin.com/in/polak-adi/

"Paddington Helps Out" is Michael Bond's third collection of short stories about Paddington - a good-hearted bear who emigrated from "Darkest Peru" and was adopted by a family in London.

The stories follow a familiar theme established by Bond in earlier collections: Paddington tries to do something kind, but invariably messes up things through his clumsiness or ignorance; yet things always work out well in the end.

We get stories of the bear trying to figure out an auction and a laundromat and a movie theater on his first visit to each. Paddington struggles trying to build a woodworking project and make dinner for his adoptive parents.

With each collection, Bond ties together the stories more tightly. In this volume, each tale leads naturally into the next and has a reference to the one before. This gives cohesion to the entire book, which takes place over only a few days.

The stories are funny and charming and a pleasure to read, regardless of your age.

Michael Dobbs is a British Lord, Margaret Thatcher's former Chief of Staff, and an author specializing in stories about British politics.

His first novel - "House of Cards" - tells the story of Frances Urquhart. In his role as Chief Whip of the UK Conservative Party, Francis works behind the scenes to persuade members to vote in the party's interests; but Urquhart has ambitions beyond his current role; and he uses his influence and his knowledge of personal secrets to manipulate the government, the media, popular opinion, and elections to advance his own career. In his climb to the top, he conspires to eliminate each of his rivals. Everyone has secrets and Urquhart knows those secrets and is able and willing to exploit them. If a rival has no damaging secrets, he will invent one. Either way, the leaks are enough to destroy or limit careers.

The story is filled with politicians and other influential people drunk on their power but doomed by their arrogance and hubris. Urquhart stands apart as the ultimate Machiavellian, manipulating events people - treating them as objects to use as pawns in his own climb. His charming facade invites others to trust him, but his cunning nature is to betray anyone when that betrayal will advance his goals.

It is also the story of Mattie Storin a beautiful and energetic young female reporter who admires Urquhart's knowledge and what she perceives as his leadership skills. He manipulates her, as well.

"House of Cards" is a political thriller, filled with intrigue and political infighting and ruthless manipulation. It focuses on the appeal of power and the corruption inherent in striving for that power. It has launched two successful television series (I have only seen the BBC version, so far) and shines a light on the darker side of politics.

I loved it!

GCast 125:

Creating a Simple node.js Application

This video shows the basics of node.js and walks you through creating a simple node.js web application

Episode 709

Henning Rauch and Vincent Philippe Lauzon on Azure Data Explorer

Henning Rauch and Vincent-Philippe Lauzon are engineers on the Azure Data Explorer team. They tell us about the purpose of this database and how to use it to store massive amounts of data with high performance.

Links:
https://techcommunity.microsoft.com/t5/azure-data-explorer-blog/bg-p/AzureDataExplorer
https://docs.microsoft.com/en-us/azure/data-explorer/data-explorer-overview

"The Luckiest" is the story of two best friends - one of whom is dying. Lissette is diagnosed with an incurable degenerative disease that will leave her unable to control her muscles until she dies of suffocation. Peter is her friend, who tries to support her and is sometimes successful. Lissette's overbearing and loving mother is the only other character in the play.

A trio of actors, along with director Cody Estle brought Melissa Ross's play to The Raven Theatre, where I saw Friday evening's performance.

Christopher Wayland and Tara Mallen are excellent as Lissette's friend and mother, respectively; but it is Cassidy Slaughter-Mason who steals the show with an emotional performance as Lissette. She quickly and tastefully changes from able-bodied to disabled in this show - a necessity, as the story is told non-linearly. The Raven is small enough that audience members can clearly see Ms. Slaughter-Mason crying real tears during several emotional scenes.

I am old enough to have lost people I love. Some went quickly and some lingered slowly. I am fortunate to have had the time to say goodbye to some of them. Some faced their death with fear and some with courage, but most with a combination of the two. This play captured that mix of feelings among the dying and among those close to the dying. We each deal with tragedy in our own way, whether it is for ourselves or for those we love.

"The Luckiest" is awkward and it is sad, and it is funny, and it is always touching.

"The Voyages of Doctor Dolittle" is Hugh Lofting's second book about the famous doctor with the ability to talk with animals. I was surprised by how much longer this book is than his debut novel - "The Story of Doctor Dolittle".

Tommy Stubbins - a young boy in Dolittle's hometown of Puddleyby on the Marsh - befriends the Doctor and narrates this story. Dolittle takes Stubbins as a ward and apprentice, teaching him to read and to talk with animals and to learn as much as the Doctor can teach him.

After helping with the murder charge acquittal of a local hermit (by translating the testimony of the hermit's dog), the Doctor and Stubbins set out on an adventure to an island off the coast of South America to find and rescue Dolittle's friend Long Arrow, who happens to be the second greatest naturalist in the world.

This is a fun ride filled with characters and adventures. Many scenes in this book found their way into the Rex Harrison movie that I loved as a child. Reading about the dog who testified at a trial and the shipwreck, and the floating island and the great glass sea snail was like revisiting an old friend after decades apart.

In some ways, "Voyages" is progressive for a book written a hundred years ago. While visiting Spain, Dolittle challenges the cruelty of the sport of bullfighting; and he befriends natives of South America and sub-Saharan Africa and treats them with respect. But one cannot ignore that the author treats these races as primitive savages, and they are saved by the white doctor - a philosophy used by many to rationalize centuries of European imperialism. If you can look past this and consider the time in which Lofting wrote his story, it is much easier to enjoy.

What are Code Reviews and Why Should We Spend Time on Them?

How Can a Code Reviewer Improve the Code Review Process?

How Can a Code Author Improve the Code Review Process?

Episode 708

Sarah Sexton on Using Technology to Stay Sane During Stressful Times

Like many of us, Sarah Sexton felt the mental burden of dealing with the isolation and risks of the COVID pandemic. Playing the social simulation game Animal Crossing: New Horizons gave her one way to cope with the stress. She discusses how this helped her to stay connected with friends, keep her mind focused, and manage her stress.

For anybody who plays Animal Crossing: New Horizons™️, here's Sarah's info:

• Dream Address, to tour her island: DA-9275-0301-6939
• Creator ID, to download her custom-made "Happy Stripes Hoodie" and other designs: MA-0416-9759-5054
• Happy Home Network ID, to tour her Happy Home Paradise™️ vacation homes: RA-0972-1430-0062

"Thanks for watching!" -Sarah

Lois McMaster Bujold has never been shy about bringing sexuality into her stories. In her novels about Miles Vorkosigan and the futuristic galaxy in which she sets his adventures, Bujold has told of a planet inhabited entirely by male homosexuals, a race of hermaphrodites, and sexual affairs with genetically altered beings.

In her latest novel - "Gentleman Jole and the Red Queen" - she reveals that Miles's father - the late Aral Vorkosigan - was bisexual. In their younger days, both Aral and his wife Cordelia had an affair with Ensign Oliver Jole. This was hinted at in earlier novels but confirmed here. Aral and Cordelia were each aware of and supportive of their partner's extramarital needs and their marriage remained strong after the affairs.

It is now three years after Aral's death. Oliver is an Admiral and Cordelia is a high-ranking government official and the two have rekindled their friendship and their romantic involvement. This new phase of their relationship begins when Cordelia announces that she plans to become a mother using frozen gametes provided by Aral before his death. She offers some of these to Oliver, so he can father a child with Aral's DNA. The sci-fi child-bearing technology can be confusing, but it all seems plausible in Bujold's universe. This book continues a common theme of the series: ethical questions that arise from new technologies.

This series has always focused on the growth of Miles as he moves through the phases of his life. Although he is a minor character in this one, we still see that growth. A middle-aged Miles is wrestling with the responsibilities of his fatherhood and struggling to understand the needs of his mother.

Cordelia has always been an important character in the series. She has influenced the character of both Aral and Miles, but she has mostly done so in the background. Miles and (to a lesser extent Aral) drove the stories. But she takes charge in this book, governing a planet, defining her relationship with Oliver, and helping a middle-aged Miles understand her relationship and her need to move forward with her life following the death of her husband.

Like most Vorkosigan novels, this is an adventure story and a character study. But it is also a love story and a story about starting over and moving on after losing a loved one. Its theme of sex and romance among older people resonated with me, as I am a single man in (probably) the final third of my life.

I do not know if this is Bujold's final Vorkosigan story; but, if it is, she has concluded on a strong note.

Lois McMaster Bujold's "Labyrinth" is a novella set in the Vorkosigan universe - one she created to hold the adventures of her hero Miles Vorkosigan.

While on a mission to the corrupt planet Jackson's Whole, Miles discovers Taura - the failed result of a genetic experiment to create a super-soldier. Taura is eight feet tall, capable of great violence and her fangs and claws give her an appearance that is more than a little frightening; but Miles senses a gentleness and sensitivity in Taura and takes pity on her mistreatment and imprisonment. He also needs some of the genetic material hidden in her calf to complete his mission. When Miles is captured, he and Taura form an unlikely couple as they plan their escape.

A version of this story appears within the novel "Borders of Infinity", but I had forgotten most of it in the five years since reading that collection, so it seemed fresh to me. In any event, the story stands on its own.

It shows off Miles's spirit of adventure, his resourcefulness, and his character. In later stories, Taura shows fierce loyalty to Miles because he was faithful to her. He not only saw past her outward appearance to the beauty within, but he kept his promise to rescue her.

This is a brief but significant story in the saga.

A Code Review can sometimes be a painful process. Reviewing code takes time and attention and human beings do not have an unlimited supply of either.

But, it does not have to be that way. There are things we can do to make a code review less painful.

There are two parties in a code review: The Author and the Reviewer. A Code Review begins when an  Author sends to a Reviewer a list of changes they made to an application. The Reviewer then looks at the code and either approves it or makes suggestions and sends it back to the Author. The process repeats until the Reviewer approves the changes.

The Author's changes are known as a "Change Set"; the description of those changes is a "Change List"; many Application Lifecycle Management tools (e.g., GitHub and Azure DevOps) support a "Pull Request", which combines the two with the source code and is a formal entry point for the Reviewer to begin reviewing the code changes. I often use these three terms interchangeably because they are so closely related.

In my last article, I describe ways that the Reviewer can improve the Code Review process.

In this article, I will describe ways that the Code Author can improve the Code Review process.

Test Your Code

This should go without saying, but you should always verify that the code works before submitting it for review.

Spend time validating that your code works. Manually run your code. Write automated tests and run them as you make changes to your code. Vary the inputs and consider edge cases and unexpected user actions as you do. A small change can break things unexpectedly and automated tests are great insurance against this.

Become a Reviewer

Code Reviews take time and effort, and you should respect the time and effort that the Reviewer commits to the process. A final scan of your code often reveals obvious problems, such as spelling errors and redundant or unnecessary code. It can even reveal more fundamental problems, such as a bug you missed on the first pass. Taking a few minutes to review your code reduces the time and effort required by the Reviewer. As a bonus, your code will look better to the Reviewer, making them more efficient and encouraging a better relationship.

Communicate clearly

A Pull Request consists of a set of changes to the code. It should always contain a description of those changes. If you write a clear description of those changes, the Reviewer will know what to look for and their feedback will be more useful.

When responding to feedback, always communicate what you changed in response to that feedback. This will give the Reviewer an idea of what to look for and make it easier for them to read and evaluate your changes.

If anything is unclear in the feedback, solicit more information - either through comments in the PR, via email, or with a verbal conversation. Written communication is sometimes flawed and requires clarification.

Use the computer

As mentioned earlier, you should test your code before submitting it to a reviewer. Much of this can be done automatically using the computer: Compile the code; run all automated unit tests; and use a linter to check the code style against a set of pre-established rules.

Answer questions with code

The clearer you make your code, the easier it will be to understand. Code comments can be useful, but you must take care to always keep them up to date with the code. The best way to clarify your code is to make it self-documenting. Well-written, self-documenting code will almost always communicate its intent better than code comments.

Spend some time refactoring your code to make it more readable. Here are some examples:

If you have lines of code that perform a property tax calculation, consider putting this into a method with a name like "CalculatePropertyTax". Calling this method is probably much clearer than trying to understand what the calculations do.

If you have a number or code with a specific meaning (for example, a tax rate or department id), assign that value to a constant, a variable, or an enum. It is much easier to read and understand this:

var taxDue = revenue * TAX_RATE

than this:

var taxDue = revenue * 0.23

Your goal should be to make the code as readable as possible. Consider questions the Reviewer might have and strive to make the code answer those questions.

Keep it Simple

I have seen too many Pull Requests that make a plethora of changes. It is best to create a Pull Request that only makes one change to the system (although you may choose to implement that change using multiple functions). If you are adding a new feature and fixing a bug, split these into two PRs. If you are changing two distinct parts of the system, split these into two PRs. Large PRs are confusing and overwhelming. The time and effort to review two PRs is almost always less than the time to review one large PR.

Breaking up large changesets can narrow the scope of your change, making each one easier to understand and review.

Sometimes, we create Pull Requests for non-functional changes, such as changing the formatting of our code. These often affect every line in a file. These should always be submitted as their own changeset. If we combine these changes with functional changes, it makes it nearly impossible to determine which lines had a functional change.

Stay Cool

Code reviews can be a source of conflict. Code Authors often feel an ownership of the code they write to the point that they perceive any criticism of their code as a criticism of themselves. Avoid this outlook. Separate yourself from your code and do not take constructive feedback personally. It will be better for your mental health, and it will allow you to look more objectively at how you can improve your code. Respond graciously to the Reviewer's feedback. You both have the same goal: to improve the quality of the codebase. Keeping your cool can be especially difficult when you know the Reviewer is mistaken. Reviewers are human and they are allowed to be wrong sometimes and you should be patient when this happens. Consider that a lack of clarity in your code may be a source of a Reviewer's mistake and strive to address this.

Recognize there are multiple right ways to do almost everything in software development. If you are both correct, it will save time and effort to skip the debate and agree with the Reviewer.

Respond quickly

This is similar to advice to the Code Reviewer. Delaying the time between receiving feedback and responding/working on the feedback slows down the entire process. The sooner you work on changes, the fresher will be the original code in your mind. The sooner you re-submit your changes, the more fresh will be the feedback in the mind of the Reviewer. This can be a challenge if you have begun some other work; but recognize that there are significant benefits to responding quickly to code review feedback.

Conclusions

Proactive thinking by a Code Author during a code review can make the whole process faster, more efficient, and more pleasant. Give a few thoughts on how you can make it better.

Code Reviews

A Code Review can sometimes be a painful process. Software developers often feel a personal attachment to their code and may feel that criticism of their code is a criticism of themselves. Reviewing code takes time and attention and human beings do not have an unlimited supply of either.

The good news is that it does not have to be that way. There are things we can do to make a code review less painful.

There are two parties in a code review: The Author and the Reviewer. In my last article, I described the code review process and listed reasons why it is worth the time and effort to do them. To summarize, a Code Review begins when an  Author sends to a Reviewer a list of changes they made to an application. The Reviewer then looks at the code and either approves it or makes suggestions and sends it back to the Author. The process repeats until the Reviewer approves the changes.

The author's changes are known as a "Change Set"; the description of those changes is a "Change List"; many Application Lifecycle Management tools (e.g., GitHub and Azure DevOps) support a "Pull Request", which combines the two with the source code and is a formal entry point for the Reviewer to begin reviewing the code changes. I often use these three terms interchangeably because they are so closely related.

In this article, I will describe ways that the Code Reviewer can improve the Code Review process.

Do Not Wait to Review

If you can begin reviewing a Pull Request immediately, it saves a lot of time and trouble. The sooner you begin, the sooner you can return any feedback and the better the chance that the code will still be fresh in the mind of the author.

In addition, it is likely the author will begin making other changes to the system after submitting a Pull Request. It is usually easier to merge code if fewer changes exist between the two branches, so a quicker turnaround makes code merges easier.

Beginning your review also shows respect for the process and for the code written by the author, improving your relationships.

Work High Level to Low Level

Always begin your evaluation by looking at high-level decisions in the code, such as class structures and method interfaces. Often, changes made at this level will address issues at a lower level, such as the implementation of the business logic.

Use the Computer where you can

You can use a computer to automate many of the mundane tasks of a code review. The computer can compile the code and run all the unit tests. A linter can validate that the style is correct.

Create a Style Guide

Speaking of style, many organizations adopt a set of style guidelines to which they expect all code to adhere. The guidelines chosen are less important than the fact that everyone is using the same style, so that code is consistent and easy to read.

You can create your own guide from scratch or start with an existing one, such as Google's style guide (google.github.io/styleguide)

Arguing over code style is usually a waste of time. Simply point to the style guide to settle any arguments. If the style guide does not cover a case, modify it to include this. This guide can evolve over time, as the team writes code and discovers areas of ambiguity in the guide.

Include Code Examples

A code example is a nice way to communicate a change to an author. This is particularly true if you suggest a pattern with which the author may be unfamiliar.

Do Not Make It Personal

Programmers often take great pride in their work and sometimes internalize critical feedback, as if criticism of the code equates to criticism of the coder.

You cannot control the way the code author thinks, but you can minimize this feeling of attack by avoiding anything personal in your feedback. If you find yourself writing "You" in your comments (for example, "You need to initialize this variable"), consider replacing it with "We".

You can soften your feedback by using a passive voice (this is one of the few times I will recommend the passive voice in written communication). For example, instead of saying "You should split this into two functions", say "This function should be split into two functions".

Another way to soften feedback is to phrase it as a request, rather than a command. For example, "Can we make this function private?" is less confrontational than "Make this function private" and is less likely to trigger a defensive reaction.

Finally, avoid advice based solely on your opinion. Instead, cite a software principal to support a suggested change. "I think this should be split into two classes" is less compelling than "This class does two different things, which violates the Single Responsibility Principle. Consider splitting it into two classes".

Prefix review comments with labels:

I recently read about a team that adds a prefix to many of their feedback comments. Here are some suggestions.

Issue: A problem with the code that needs to be addressed
Suggestion: A possible way of addressing an issue
Question: A request for clarification. Useful if the reviewer is unsure if something is an issue
Nit: A trivial change
Thought: An idea for improving the code that the author may or may not choose to implement
Praise: Point out something good in the code

You can read more about this idea here.

Praise Sincerely

I love the idea of adding praise in the reviewer's feedback. So often, we think of feedback as only negative, but it is also a chance to call out something positive.

Goal: Improve Code

Some reviewers insist that every issue needs to be fixed before they approve a PR. This can lead to very long review cycles and bitter feelings between the author and reviewer.

There are a few ways to avoid these long review cycles.

One way is to set a goal to improve the code, rather than to make it perfect. Blogger Michael Lynch uses the phrase "Aim to bring the code up a letter grade or two" to describe this. If we receive code that is a "C" grade, and we can bump it up to a "B", that is a win, even if there are still issues to be addressed. Chances are the code author will learn something from the feedback and their next set of code will start closer to a "B", making it easier to move it to an "A" in a review. Of course, we want to prioritize the most critical issues to fix.

If only trivial fixes remain in a PR, it is OK to approve it.

Finally, if a PR contains a large number of changes, suggest splitting it into multiple PRs to make it more manageable. Suggesting where to split the code is very helpful in this case.

Avoid Repeating Feedback

It is not uncommon for the same issue to appear multiple times in the same PR. Do not waste time re-typing the same comment. A line like "See naming convention comment above" will suffice.

Consider the Scope of the Review

As a general rule, you should only review and provide feedback on those lines that the author changed. This helps to limit the review cycle.

There are some exceptions to this rule, in my opinion:

• If a change affected a line that did not itself change (for example, the code in a method was modified and the name of the method no longer reflects what it does)
  
• If a change is trivial and easy to fix (for example, you spot a spelling error in a line of code that did not change)

Stalemates

Sometimes, a Code Review process gets stuck as the Author and Reviewer argue over whether something needs to change. This can prevent the review from moving forward; but, it can also result in tension between the two parties, which may hinder future reviews.

When you recognize a stalemate occurs, the first step should be to discuss it verbally. Code Review communication is usually written, which can sometimes be misinterpreted. Walk over to the other party's desk or schedule a virtual call to talk about the conflict and how to resolve it.

For disagreements on fundamental design decisions, you may need to schedule a formal design review. This was likely something that was missed during the original design.

Consider whether your opinion is worth blocking a PR. Software development contains very little dogma and often there are multiple correct answers to the same problem. If the other party's solution will work, consider conceding your point.

As a last resort, you may need to escalate the conflict to an architect or manager and allow them to resolve it.

The last thing you want is for a Code Review to hold up a Pull Request merge indefinitely.

Conclusion

The benefits of Code Reviews almost always outweigh the costs. As a Code Reviewer, you can take action to reduce the cost of a Code Review in terms of time, effort, and stress.

A Parable

John spent days writing a software component. He tested and double-checked his code, and he was satisfied that it worked properly, according to the requirements he was given, so he checked it into source control. A few weeks later, a new version of the software that included his code was released to production. A user discovered a bug caused by John's changes. The user tweeted about the bug, and this was retweeted thousands of times. Before long, word got back to John. An edge case that John had not considered was causing problems in production. He fixed the bug and checked his changes back into source control. And he waited. Hoping for the best.

June spent days writing a software component. She tested and double-checked her code, and she was satisfied that it worked properly, according to the requirements she was given, so she checked it into source control. June's team had a policy that required a code review prior to merging any code with the main branch. During the code review process, one of June's peers pointed out a bug in her code. It was an edge case that June had not considered. She fixed the bug and checked her changes back into source control. The code was reviewed again and merged with the main branch. June slept well that night.

The story of June and John illustrates some of the advantages of code reviews. Catching June's bug during a code review resulted in a faster and cheaper fix and resulted in less public embarrassment than catching John's bug in production. The two bugs were of equal severity, but one was less costly to fix.

What is a Code Review?

Why do we do code reviews? They take up time that could be spent writing code, designing features, or otherwise directly driving forward a project, so there is a cost. The answer is that the benefits of a good code review far outweigh the costs.

When I think of a code review, I think of a formal process in which one person reviews code written by another and provides written or oral feedback to the author, approving that code only after they deem it acceptable.

There are two parties in a code review: The Code Author and the Code Reviewer.

The steps in a code review are:

1. The Code Author makes changes to an application and checks those changes into a code repository
2. The author sends a description of changes to the Code Reviewer. The changes are known as a "Change Set"; the description of those changes is a "Change List"; many Application Lifecycle Management tools (e.g., GitHub and Azure DevOps) support a "Pull Request", which combines the two with the source code and is a formal entry point for the Reviewer to begin reviewing the code changes. I often use these three terms interchangeably because they are so closely related
3. The Code Reviewer retrieves the code, examines it, and (if necessary) provides feedback on changes that the author must make before the code can be merged with the main branch
4. If the code requires changes, the Reviewer sends the feedback to the Author
5. The Author responds to the feedback and makes any necessary changes
6. The Author re-sends to the Reviewer the code with these updates
7. Steps 3-6 are repeated until no more changes are required
8. When no more changes are required, the Reviewer approves the changeset
9. The code is merged with the main branch in the repository

Code Review Goals

A good code review will accomplish the following:

• Validate code
• Help make engineering decisions
• Share knowledge
• Increase code ownership

Let's discuss each of these goals.

Validate code

The most obvious reason to review code is to validate that it does what it is supposed to do. Generally, we look at this from an external point of view. For example, if we provide a given set of inputs to a function, we verify that the function returns the expected output. We can pull the code from source control and make sure it compiles and runs successfully. We can execute automated tests and validate that they all pass.

But we also want to validate the code from an internal point of view. If our team has coding standards, does the code adhere to those standards? While reviewing code, the reviewer looks for and calls out potential problems. Even if the code works well, there may be potential areas for improvement. For example, the reviewer may suggest ways to make the code more efficient, faster, or more readable. The reviewer should point out these as well.

Help make engineering decisions

Sometimes, a code review can drive engineering decisions. If there is confusion or inconsistency about how the application is accessing data or dividing services or testing code, code reviews can raise these issues and prompt a discussion. If different developers have different coding standards, it may indicate a gap in the team's standards and drive discussion around this.

Effective teams have published a set of coding guidelines that may describe everything from naming conventions to required test coverage. Developers must be aware of these guidelines and make an effort to adhere to them; but often non-compliant code slips through. A code review is a good place to catch this before the code is committed to the main branch.

Sharing knowledge

Another benefit of Code Reviews is that it allows sharing of knowledge.

There are two parties involved in a code review process: the code author and the code reviewer. By reviewing the code, the reviewer has a chance to improve the code itself and to address any weaknesses or knowledge gaps in the developer. Similarly, the reviewer can address his or her own weaknesses by seeing someone else's approach to a coding challenge.

The reviewer gains knowledge about a part of the system that someone else wrote. By reading the code, they may also learn something about the language in which it was written; or about a framework or a design pattern or an algorithm implemented by the author; or about the business cases and requirements of the application.

In addition, the code author can learn by reading feedback from the reviewer, who may suggest improvements that the coder did not consider.

Increase code ownership

I have worked on too many systems in which one developer possessed all knowledge about a part of that system. Confusion reigned when that developer left the team. No one understood how to maintain the orphaned code. By conducting regular code reviews, team members have a chance to understand parts of the system on which they are not actively working. This shared knowledge benefits the whole team, allowing flexibility in staffing and removing the danger of all knowledge departing when a team member departs.

Code Review Process

The process of a code review is simple: The author checks code changes into a repository and announces that it is available for review. A reviewer looks at and runs the code and provides feedback. This feedback can be either written or verbal. Most Application Lifecycle Management systems (e.g., GitHub and Azure DevOps) support this process through a Pull Request. In these systems, the code of a Pull Request does not get merged into the main branch until one or more reviewers have approved it. We can configure these systems, setting specific rules about who must approve code before it is merged.

This process works best when everyone involved believes in it and considers code review time to be well-spent. Support from upper management can help encourage the process; but, public buy-in from the team's most respected developers is an even more effective way to get others to buy into this process.

Conclusion

Code Reviews have become an important part of most of the projects on which I work, yet I remember a time before I even knew such a thing existed.

These days, code reviews are almost ubiquitous on my software projects. They help us address weaknesses among developers and reviewers, enforce compliance with coding standards, and improve the quality of our codebase.

If we can catch bugs before they go into production, we can save ourselves embarrassment, time, and money. A good code review process helps us achieve that.

Episode 707

Beijie Zhang on Technical Interviews

Beijie Zhang has conducted dozens of interviews with developers applying for tech jobs. He describes the structure of these interviews and how a candidate can prepare.

Link:

BetterLogic channel

5/2
Today I am grateful to sit in a coffee shop and read a book for a couple hours yesterday afternoon.

5/3
Today I am grateful for 500 subscribers to my GCast YouTube channel

5/4
Today I am grateful for an informative conversation with Dave yesterday.

5/5
Today I am grateful for coffee with Adam yesterday.

5/6
Today I am grateful to see Joe Lovano perform on my first visit to the Village Vanguard.

5/7
Today I am grateful for my first visit to the Museum of Modern Art yesterday

5/8
Today I am grateful to all the excellent mothers who make this world a better place

5/9
Today I am grateful to the hotel that mailed back to me the library book I left in my room.

5/10
Today I am grateful for supportive conversations with Shahed, Nick, and Tony

5/11
Today I am grateful to talk about the tech community yesterday with Eric

5/12
Today I am grateful for warm weather in Chicago

5/13
Today I am grateful to arrive safely in Tampa.

5/14
Today I am grateful to meet so many of my current and future family yesterday.

5/15
Today I am grateful for a rehearsal lunch and an evening get-together last night in Tampa.

5/16
Today I am grateful
-to attend the wedding of my son Nick
-to welcome Adriana into our family
-for a wonderful 4 days in Tampa

5/17
Today I am grateful
-to arrive safely in Seattle after a full day of flying
-for dinner last night with my team

5/18
Today I am grateful for a day of hacking in Seattle

5/19
Today I am grateful for dinner with Glenn and his daughter last night.

5/20
Today I am grateful for an evening at the Seattle Aquarium

5/21
Today I am grateful for dinner with Ted last night.

5/22
Today I am grateful for breakfast with Josh yesterday

5/23
Today I am grateful for breakfast yesterday with Dave, Sue, Debora, and Gary

5/24
Today I am grateful for a gift of Hello Fresh meals from my son and daughter-in-law

5/25
Today I am grateful for a conversation with Tim yesterday for the first time in years

5/26
Today I am grateful to connect and talk with Tiberiu yesterday.

5/27
Today I am grateful to see the SteelDrivers in concert last night.

5/28
Today I am grateful to accept an offer of a new job at Microsoft.

5/29
Today I am grateful to see a production of "Spring Awakening" yesterday at the Ruth Page Center for the Arts.

5/30
Today I am grateful to all the men and women who gave their lives in defense of our country.

5/31
Today I am grateful for a 3-day weekend

6/1
Today I am grateful for a fresh start

6/2
Today I am grateful for many good wishes the past few days

6/3
Today I am grateful for pizza with Tim last night

6/4
Today I am grateful to see a performance of "Rasheeda Speaking" at Theater Wit last night.

6/5
Today I am grateful to sit on the patio at Fitzgerald's listening to live music yesterday afternoon.

Sometimes, the last few pages overshadow the rest of a book - even when those pages have nothing to do with the rest of the story.

In "Cryoburn", Lois McMaster Bujold continues the adventure of Miles Vorkosigan, the diminutive galactic Lord and Imperial Auditor.

After being drugged and kidnapped while investigating corruption on the planet Kibou-daini, Miles awakens in a semi-abandoned building to discover a plot to cover up corporate bungling that will result in the death of thousands. He is rescued by Jin, an orphan and runaway, who is hiding in an underground operation that uses technology to "freeze" the terminally ill until a cure for their disease can be found.

McMaster takes us on a fun journey as Miles tries to unravel the conspiracy on this planet. He is assisted by Jin and by armsman Roic, Miles's right-hand man.

Although Miles is the focus of much of the story, the point of view switches mostly between Jin and Roic. The narrative is in the third person, but the language changes depending on the point of view. Most notably, Roic, refers to Miles as m'lord, while Jin calls him Miles-san.

This is the first time I remember an ethnicity or culture from Earth influencing the story, but it is clear from the names and the language that Kibou-daini is populated by the descendants of the people of Japan.

Bujold drops a bombshell at the end of the story that probably deserves more buildup; but her technique mirrors the random ways that major life events often strike in our lives, so it works.

"Cryoburn" works as a detective story, an adventure story, a science fiction story, and a story of corruption and class struggles.

But it is the final chapter that stays with me.

Episode 706

Dasith Wijesiriwardena on OpenTelemetry

OpenTelemetry is a set of standards, SDKs and tools that allow us to implement tracing in a distributed system.

Microsoft Engineer Dasith Wijesiriwardena describes how we can use OpenTelemetry to improve observability and make it easier to analyze distributed applications.

"Spring Awakening" breaks a lot of rules and pushes the envelope on others. It includes topics of child molestation, masturbation, teenage sex, abortion, and suicide; and it expresses many of these through the catchy melodies of Duncan Sheik and the lyrics of Steven Sater.

This is the story of a group of young people at a restrictive school in 19th-century Germany. Most of them have been mistreated by adults in their life, including their parents and they bear the scars of this mistreatment.

Local Chicago company Porchlight Theatre produced an excellent rendition of this musical at the Ruth Page Center for the Arts in Chicago's Gold Coast.

The play focuses on Melchior (played by Jack DeCesare) and Wendla (played by Maya Lou Hlava) - two star-crossed lovers struggling to find their identities without the benefit of role models.

But Quinn Kelch steals the show as Moritz, a marginal student driven to despair by the thought of failing out of school. His wild-eyed neuroses and magnificent voice energized the show. Early in the play, Moritz surprises the audience in the middle of a mournful soliloquy when he pulls a microphone from his schoolboy uniform, jumps up on a chair, and launches into the rebellious anthem "Bitch of Living". The rest of the cast joins in, taking turns railing against their maltreatment or announcing their angst and sexual frustration.

The show is full of surprises. The same two people play every adult role: Michael Joseph Mitchell for the men and McKinley Carter for the women. The context and some slight costume changes make it clear who is who.

The music takes the audience on an emotional roller coaster, swinging from anger to sadness to hope.

This was a low-budget production staged entirely with local actors, directors, and staff. It lacked the sets and glitter of a Broadway show. The focus was entirely on the story and the characters. I was moved by it.

Sometimes the loss of a major talent destroys a band; and sometimes, that band keeps moving forward and continues producing excellent material. The SteelDrivers experienced the latter.

In 2010, founding member Chris Stapleton left the group and went on to a successful solo career. The band has had three lead singers since then, but the lineup has remained relatively stable otherwise and has earned multiple Grammy nominations and one Grammy Award. Current singer Matt Dame has the voice to drive forward the band's music.

Thursday night, The SteelDrivers performed at The City Winery, delighting the crowd with their songs and their energy.

In addition to Dame, the current lineup consists of Tammy Rogers (fiddle and vocals), Richard Bailey (banjo), Mike Fleming (bass and vocals), and Brent Truitt (mandolin).

Rogers took the reins of this show, introducing the songs and charming the audience with humorous stories. The show was scheduled as part of a tour that should have happened two years ago to promote their "Bad for You" album. That album was released a few weeks before a global pandemic shut down much of the world, including the SteelDrivers tour. Rogers informed us that SteelDrivers fans are known as "Steelheads" and she hoped we would all leave as Steelheads tonight.

The band takes pride in performing only their own songs, steering clear of covering other songwriters' material; and they have an impressive list of songs on their five albums from which to choose. By their own admission, the songs tend to be autobiographical, but they leave it to the audience to decide what is fact and what is fiction.

They play bluegrass music, but it is bluegrass with a mix of blues and country - a good combination that empowered the music.

The band sounded better and better as the night went on. The audience drew spirit from the band and the band from the audience. Highlights included the emotional "Ghosts of Mississippi", the traditional country song "Lonely and Being Along", and "Blue Side of the Mountain" - a song recently covered by a contestant on American Idol. They returned for one encore: "Where Rainbows Never Die", a fan favourite.

I was a casual fan at the start of the evening. By the end of the concert, I was a Steelhead.

GCast 124:

Customizing Spelling and Grammar Checks in Microsoft Word

Learn how to customize the spelling and grammar checker in Microsoft word: Enable and disable grammar checking, set the language and dialect, and ignore spellchecker in parts of your document.

When I was a boy, my parents took me to see Doctor Dolittle - a charming musical film in which Rex Harrison played a globetrotting veterinarian who had the ability to talk with animals in their own language. It quickly became my favourite movie and I watched it every time it was on TV. I was vaguely aware that the title character was based on a series of novels, but I never read these books. Until now.

Hugh Lofting's 1920 novel "The Story of Doctor Dolittle" introduced the title character. He was an M.D. but he had so many pets in his home that his patients refused to visit, and his sister eventually moved out, leaving no one to care for him. His pet parrot Polynesia taught the Doctor the languages of other animals and soon he developed a reputation as the most effective veterinarian in England. His reputation spread to Africa, where he was asked to come and cure a colony of sick monkeys.

On his journey, he was kidnapped by an African king, hunted by pirates, and rescued an old man from a cave. Most of his success was due to the help of the local animals.

It is worth noting that at least one scene does not age well. When we first encounter the African king, he is angry at the white Europeans thanks to the exploitation he experienced from previous imperialist visitors. These seemed progressive for a book written a hundred years ago; but a few chapters later, the king's son asks the Doctor to fulfill his dream of becoming a "White Prince". This scene has been cut from some editions, but it was left in the one I read, and it will not sit well with most modern readers. It appears that some racial epithets were removed from this edition.

Despite that, the story is fun, even for a grown-up like me. Lofting leads us from adventure to adventure and it is Dolittle's kindness to animals that is his greatest strength.

Episode 705

Douglas Starnes on Python and Azure

Douglas Starnes discusses how Azure, Visual Studio Code, GitHub Codespaces, and other Microsoft tools support Python and Linux tools.

Robert Jordan's "The Dragon Reborn" continues the adventures of the heroes of "The Wheel of Time" series. As in the first two books, volume three has the characters split up and travel across the world Jordan has created.

It was not a well-kept secret, but the previous book ended with an astral projection of Rand al'Thor's battle with Ba'alzamon Now virtually everyone in this world knows that Rand is The Dragon Reborn - the powerful male mystic, who is destined to change the world in a way that will either save or destory it; and he will likely be driven mad by the power he wields.

Rand sets out on a quest to find his destiny. Moiraine, Lan, Loial, and Perrin depart soon after to search for him. Egwene, Nynaeve, and Elayne move forward with their training to become full sisters of the mystical female Aes Sedai order; then go searching for the Black Ajah Liandran, who betrayed the Aes Sedai. Perrin wrestles with his growing connection with wolves, while Mat is finally cured of the evil that infected him when he stole a cursed blade.

In the end, the major players converge in the province of Tear and Rand again fights the dark lord Ba'alzamon, believing again this is the final battle between the two.

Oddly, the title of this book refers to Rand; we hear far less of him in these pages than of his companions. This worked, as the reader gets more development of the other characters - particularly Mat and Perrin. All these quests, characters, and subplots can confuse the reader. Fortunately, in this novel, Jordan stays longer with each group and place, allowing the reader to gain a comfort level with the plot thread he is exploring.

The Wheel of Time is a marathon and not a sprint and it is best to keep this in mind as Jordan builds his world and his characters. We learn more about his characters as they learn more about themselves.

Episode 704

Shannon Kuehn on Workload Identity Federation

Shannon Kuehn describes how to use Microsoft Workload Identity Federation to simplify authentication across Azure and other systems.

Links:
Shannon's blog

GitHub Federated Identity (Microsoft documentation)

GitHub Federated Identity (GitHub documentation)

Gallant GitHub Code (Az-CLI script)

"More About Paddington" is Michael Bond's second collection of stories about Paddington the Bear. As in the first collection, each story relates an incident or adventure in the life of the good-hearted anthropomorphic bear and the English family that has taken him in.

Each story follows a similar pattern: Paddington has an idea and sets out with the best of intentions; things go wrong and sometimes things get messy; everything works out well in the end. They are cute stories aimed at children, but they entertain enough to appeal to adults.

The stories in this collection are more cohesive than in the previous book. Each tale references the one before and they all take place over a period of a few months at the end of the year.

Paddington is quickly becoming one of my favourite characters in children's literature.

Tom Harrell was born before the founding of Jazz Showcase, the southside club at which he performed Saturday night. Harrell looks every bit of his 75 years. He is old and frail and incapable of sitting erect in his chair. But he can still play, and his playing is still impressive.

Harrell has played with Stan Kenton, Woody Herman, Dizzy Gillespie, and a host of other jazz legends over the years; and he still loves the music enough to climb onto a stage and lead his quartet for two sets. The quartet was a terrific set of talent that included Ugonna Okegwo on bass and Adam Cruz on drums. But it was Venezuelan pianist Luis Perdomo who stole the show with his outstanding technique and solos.

Highlights of the evening included "Sea", a beautiful melody, which Harrell dedicated to the late Joe Siegel, who founded Jazz Showcase three-quarters of a century ago; and his version of John Coltrane's classic "Moment's Notice".

Although there was not much visually to the performance, the music was enough to satisfy a full house.

Articles

The Advantages of Azure Data Explorer

Creating an Azure Data Explorer Cluster

Creating an ADX Database

Creating an Azure Data Explorer Table

Using ADX Commands to Manage ADX Tables

Kusto Query Language Basics

Analyzing ADX Time Series Data with KQL

Geo Functions in KQL

Working with ADX Materialized Views

ADX User-Defined Tabular Data Functions

ADX User-Defined Scalar Functions

Ingesting Data from Azure Storage Blobs into an ADX Table

Videos

GCast 117: Getting Started with Azure Data Explorer

GCast 118: Managing Azure Data Explorer Tables with ADX Commands

GCast 119: Kusto Query Language Basics

GCast 120: Analyzing Time Series Data with KQL

GCast 121: Analyzing Geographic Data with KQL

GCast 122: Azure Data Explorer Materialized Views

GCast 123: Ingesting Into an ADX Table From an Azure Storage Blob

Henning Rauch and Vincent Philippe Lauzon on Azure Data Explorer [TECHNOLOGYANDFRIENDS 709]

Episode 703

Mary Grygleski on Event Streaming and Processing with Apache Pulsar

Mary Grygleski describes how to use the Apache Pulsar open source product and its connectors to build scalable applications in pieces.

Links:
https://pulsar.apache.org/
https://pulsar-neighborhood.github.io/

4/4
Today I am grateful for lunch in Little India with Nick yesterday.

4/5
Today I am grateful for a tune-up for my bicycle.

4/6
Today I am grateful to mentor Chicago high school students on their STEM project for the fourth year in a row.

4/7
Today I am grateful to see Sean Hayes in "Good Night, Oscar" at the Goodman Theatre last night.

4/8
Today I am grateful to get some legal protection against the person who has been threatening me for the past year.

4/9
Today I am grateful to see "King James" at the Steppenwolf Theatre last night with family and friends.

4/10
Today I am grateful that my sons took me to a Cubs game yesterday as a late birthday gift.

4/11
Today I am grateful for my first visit to the Field Museum in years.

4/12
Today I am grateful for a conversation with Glenn last night for the first time in too long.

4/13
Today I am grateful for 700 episodes of #TechnologyAndFriends and to all those who made it possible.

4/14
Today I am grateful for dinner last night with Nick and Tim before they flies out of town for Nick's bachelor party.

4/15
Today I am grateful for a long conversation yesterday with Jennifer and for the help, advice, and support she gave me.

4/16
Today I am grateful to celebrate Seder with friends last night for the beginning of Passover.

4/17
Today I am grateful for lunch with Debbie and her family yesterday.

4/18
Today I am grateful to celebrate a Virtual Easter with family and friends yesterday.

4/19
Today I am grateful
-to arrive safely in California
-that my abstinence from meat and alcohol is at an end
-to file my taxes on time

4/20
Today I am grateful to finally meet in person the people I have been working with for the past 6 months.

4/21
Today I am grateful for:
-a visit to 3 vineyards in central California
-coffee with Neha yesterday morning

4/22
Today I am grateful to successfully wrap up a customer project this week.

4/23
Today I am grateful for:
-Coffee with Christine yesterday morning
-Lunch with John yesterday
-My first visit to the newly-opened Microsoft office in Mountain View, CA

4/24
Today I am grateful to see the Tom Harrell Quartet in concert at Jazz Showcase last night.

4/25
Today I am grateful to bring out the cushions yesterday for the chairs on my balcony.

4/26
Today I am grateful for my fourth COVID vaccination shot.

4/27
Today I am grateful to those who offered support to me yesterday and for those who shared their own struggles.

4/28
Today I am grateful for co-workers who say and write nice things about me.

4/29
Today I am grateful to attend the ISTC STEM Challenge Showcase yesterday at the Chicago Cultural Center.

4/30
Today I am grateful that I no longer have to live paycheck to paycheck.

5/1
Today I am grateful to hear some excellent stories at The Moth Grand Slam last night.

American men are funny. So many of us like sports and talk about sports and even build friendships primarily on the basis of our shared love of a game or a team.

Rajiv Joseph's play "King James" follows two Cleveland Cavaliers basketball fans, who meet during LeBron James's rookie season. The city of Cleveland has not won a championship in over 50 years and sports fans are energized by the possibility of James - a generational talent drafted by the Cavaliers - changing that. Shawn (Glenn Davis) and Matt (Chris Perfetti) bond over their fandom and become best friends. So much of their friendship is based on their love of basketball and the Cavs. They debate, celebrate, and mourn as LeBron's career and decisions impact the team and its fans.

But the play is not about sports and the expectations that fans have of their athletic heroes.

But ultimately, sports was a red herring; it was nothing more than a reason to bring together the two friends. "King James" is more about relationships and friendships and how people understand one another and communicate. I saw myself in both Shawn and Matt and I felt their struggles. It was a bromantic comedy that even a bro would enjoy.

I left with a feeling of hope - hope that Cleveland sports fans must have felt following the 2016 NBA Finals.

Articles

A Sample JavaScript App Using the Bing Spell Check API

Calling the Bing Spell Check Service

Creating a Bing Spell Check Service

Calling the "Recognize Text" Cognitive Service from a .NET Application

Passing a binary file to a web service from a .NET app

Converting Images to Text with the "Recognize Text" API

Calling Cognitive Services OCR Service from a .NET Application

Calling Cognitive Service OCR service from JavaScript

Using the Cognitive Services OCR Service

Getting Started with the Cognitive Services Computer Vision API

Introducing Cognitive Services and Computer Vision

Natural Language Processing with LUIS

Cognitive Services Optical Character Recognition

Using the Cognitive Services Emotion API

Using Cognitive Services to Generate a Thumbnail Image

Generating a Cognitive Services API Key

Cognitive Services Make It Easy to Use Machine Learning in Your Application

Screencasts

Introducing Cognitive Services and Computer Vision

Creating Applications with the Analyze Image Cognitive Services API

OCR with Cognitive Services

Handwriting OCR with Cognitive Services

Cognitive Services Text Recognition service

Text Recognition Cognitive Service with Binary Images

Text Recognition C# Demo

Sentiment Analysis Cognitive Service

Sentiment Analysis JavaScript Demo

Using the Video Indexer AI Tool

Interviews

Sam Nasr on Cognitive Services

Martin Kearn on Document Recognition and Knowledge Extraction

Hamayal Choudhry and Samin Khan on SmartArm

Presentations

"Building and Training your own Custom Image Recognition AI" presentation at NDC-Oslo

Talking about Cognitive Services on the Eat Sleep Code podcast

GCast 123:

Ingesting Into an ADX Table From an Azure Storage Blob

In this video, you will learn to ingest data from an Azure Storage Blob into an ADX table. This is useful when you have a large amount of data to ingest.

After ten years working on Agile projects, I have discovered that just about everyone has their own spin on how to do it effectively.

Esther Derby and Diana Larsen emphasize frequent retrospectives, which they describe in their appropriately titled book "Agile Retrospectives: Making Good Teams Great".

I have been on many projects that waited until they ended before doing any kind of retrospectives - an event often referred to as a "Post-mortem". I have found these to be of little value. We spend a lot of time analyzing what went right and what went wrong, and we document it thoroughly and we file it away where no one reads it.

"Agile Retrospectives" suggests a more agile approach - conducting an analysis periodically throughout the project and using the information gathered to adjust the team's behavior and goals going forward.

Following a brief introduction describing the history and purpose of retrospectives, most of the book is devoted to a set of activities that one can organize and participate in during a retrospective. Each activity is broken down into the following:

• Purpose
• Time Needed
• Description
• Steps
• Materials and Preparation
• Examples

In addition, the authors sometimes list variations on the steps and description of an activity.

Each chapter reads like a set of recipes and this cookbook format makes it simple to select and follow each "recipe". While this book focuses primarily on retrospectives throughout a project - after each sprint, for example - many of the ideas and activities could also be executed at the end of a project or major deliverable.

One would not and should not attempt to involve their team in every activity described. There simply is not enough time and you will find that some activities are more relevant to your team than others. However, "Agile Retrospectives" contains enough good ideas to help you improve the next iteration by learning from the previous one. Read them all and pick those that will help your team.

I have always viewed Agile methodologies as a way to get and react to feedback as quickly as possible. The activities on this book will help your team do this.

Episode 702

Joe Kunk on Windows UI Testing

Joe Kunk describes how he uses the FlaUI open source tool to automate the testing of his WPF, Windows forms and modern apps.

Until I purchased my current condominium four years ago, I had always been the one responsible for cleaning my own home. But shortly after I moved in, I decided to hire someone to clean my place regularly. Bogu was referred to me by a friend, so I hired her to come every two weeks. The only exceptions were the times I was traveling.

For the next four years, she worked for me. She was punctual, flexible, hard-working, efficient, and thorough. I told her what to do and she did it, spending about 2.5 hours on each visit and keeping my home in good shape.

We never became close personally. Bogu spoke very little English, and I tried to stay out of her way when she was working. But I appreciated her work and her attitude, and we always greeted one another with a smile.

After this past Christmas, she stopped coming. I received no phone call or text message, and she did not respond to any of my messages. This was unusual, as she had always been very responsive. I called my friends who had referred her, and they knew nothing. I did not know any of Bogu's friends or family, so I had no way of knowing her situation.

Earlier this month, my friend called with the news. In early January, Bogu had died in her sleep. One morning, she simply did not wake up.

Bogu was a Polish immigrant who worked hard her entire life and never had a chance to enjoy retirement. I never heard her complain about anything. There are many such people in our country and in our world and most of them are forgotten.

I will remember Bogu.

In 1958, Oscar Lavant was well known as a pianist, actor, and humorist. It was his sarcastic wit that set him apart and the reason that Jack Parr invited him as a guest on The Tonight Show. Unknown to Parr, Lavant's wife had him committed to a hospital to treat him for his drug addictions and temper. Luckily (or unluckily) he was released for a few hours to perform on Parr's show.

"Good Night, Oscar" - a play by Doug Wright - tells the story of that night.

The story moves seamlessly from hilarious one-liners to poignant moments between husband and wife to the tragedy of a man battling his demons. It is a roller coaster ride of emotions.

Sean Hayes, famous as Jack in the long-running TV show "Will & Grace" - is brilliant as Lavant. He captures a talented, but tortured soul, who craves an audience but deflects praise. He is the personification of imposter syndrome, forever comparing himself to his late friend George Gershwin to whom he can never live up. Portraying mental illness on stage or screen is always risky, but Hayes pulls it off successfully.

At the end, Hayes surprises us all with a vibrant rendition of Gershwin's "Rhapsody in Blue".

I have no idea how much of this story is true, but it was true for me. I felt the pain of the characters and I felt Lavant's need to salve his inadequacies with his caustic wit.

I came away more than satisfied.

Episode 701

Mihai Tataran on the Microsoft Azure Well Architected Framework

Mihai Tataran describes the Microsoft Azure Well-Architected Framework and how you can use its guidance to build a better cloud application - whether you are starting from scratch or migrating an existing application.

Somehow, I missed Paddington as I was growing up. I missed him again as my children were growing up. I did not want to wait around for grandchildren, so I picked up "A Bear Called Paddington" - the first of fourteen novels written by Englishman Michael Bond about an anthropomorphic bear discovered by the Brown family in London's Paddington Station.

It was delightful!

The Browns discover a bear in Paddington Station and learn that he has stowed away on a ship from "Darkest Peru". They take him home and name him after the station in which they found him. He quickly becomes part of the family. Although Paddington is honest, polite, and kind, his curiosity and curious nature often get him into trouble.

This book does not contain an overall plot; rather, each chapter is a self-contained short story, and they are all loosely tied together. Each story relates an incident in which the bear finds himself in an unexpected predicament because, as Paddington admits "Things are always happening to me. I’m that sort of bear." It takes only a few pages for things to work themselves out - sometimes by luck and sometimes thanks to Paddington's positive attitude and usually for the best.

Although marketed as a children's book, this novel will appeal to readers of all ages. It is honest and funny and fun and full of adventure. It's that sort of book!

When I create a new software project, I often create a folder structure to hold components that I intend to write later. Sometimes thes folders are empty in early iterations - a reminder to me and others of where things should go.

This presents a problem when working with git source control. Empty folders are ignored by git, so they never make their way into the source control system.

The solution is to add a file to the folder, so it is no longer empty. Many people will add an empty text file named ".gitkeep". If a folder contains any file (even an empty one), git will not ignore it.

Technically this is a hack, but it's common enough that we can think of it as a psuedo-standard. Naming the file ".gitkeep" lets people know the purpose of this file and that it can be removed when useful files are added to the folder.

GCast 122:

Azure Data Explorer Materialized Views

Materialized Views are a features of Azure Data Explorer (ADX) that allow you to pre-aggregate data, making queries much faster. This video shows you how to create and use a Materialized View.

Overview

When designing a cloud application, there are many options. Even if you have settled on a cloud provider, the number of services from which to choose can be overwhelming. It helps if you group cloud services into three categories: Software as a Service (SAAS), Platform as a Service (SAAS),  and Infrastructure as a Service (SAAS). There may be some overlap between these services but thinking of them in this way can simplify your options.

Software as a Service (SAAS)

Software as a Service (or "SAAS" for short) describes services that are pre-built. You can sign up for them and start using them immediately with little or no configuration. Examples include email services, such as Gmail and Customer Relationship Management systems, such as Microsoft CRM. Many of these systems allow you to customize them, but that is your choice. If they match your needs, you can sign up and start using them very quickly.

These are the simplest services to use, as they require the least amount of custom code.

Platform as a Service (PAAS)

Platform as a Service (or "PAAS" for short) describes services you can consume or build on within your applications. They provide some basic functionality, such as a website, a web service, a database, or machine learning models. But they require some custom code on your part to make them useful. These services free you from implementing part of the application, so you can focus on the business logic.

For example, if you want to implement custom vision recognition in your software, you could create and train your own model or you could simply call the Custom Vision API of Microsoft Cognitive Services. The latter is much simpler because much of the data collection and compute processing has been done for you to create an existing model. You can then take the results of that model, use it to identify objects in a photo or video, and build the business logic of your application with that identification information. 

Infrastructure as a Service (IAAS) refers to software components that are pre-built

Infrastructure as a Service (or "IAAS" for short) describes the deployment of your data and code to a virtual machine or a container in the cloud. With this category, you are responsible for all the code and data, but the networking, infrastructure, and hardware are abstracted away from you. Those things are handled by the cloud provider automatically.

On-Premises

The final category used to be our only option. In years past, we had to buy, install, configure, and maintain our own hardware. In addition, we were responsible for installing and patching the operating system and any packaged software we are using. Each of the cloud solutions described above takes that responsibility away from us.

How to decide

As a general rule, it is more cost-effective to buy or rent a solution that fits your needs than to build that system yourself. This may be offset by the amount of customization you need to do, so take this into account when you choose your services.

We can think of the categories above as existing on a continuum, as shown below:

SAAS -> PAAS -> IAAS -> On-Premises

As we move from left to right along this continuum, we gain more control over our system; but we are required to do more of the work ourselves. Doing the work ourselves tends to be expensive because we cannot share that development cost among many customers, as a cloud provider can. On the other hand, we may require flexibility that is not offered by a given service, so we may need to move to the right and absorb that cost to gain that flexibility.

My recommendation when creating an application or service is to begin on the left side of the continuum above and consider if a service in that category will meet your needs. If it does, then stop and consider using that service. If not, move to the right and consider if the next category meets your needs, and so on.

If you can find a SAAS service that you can use, you should strongly consider that. It may be that no such service exists or that all are prohibitively expensive. If that is the case, look at PAAS services and try to find one or more that will meet your needs. If no such service exists, you may need to write your own. In this case, it may be possible to deploy your solution to a different PAAS service (Microsoft App Services and Microsoft CosmosDB, for example). However, if no PAAS service meets your needs, you may need to install and deploy everything yourself. The cloud can still help as you can deploy to IAAS services, using Virtual Machines and containers. You are still freed from maintaining the hardware and underlying infrastructure of the network.

Finally, there may be reasons you cannot deploy your application or data to the cloud. Accessing data or services across the Internet may result in unacceptable latency for your application or local laws may require you to store data in a country in which no cloud data center exists. In these cases, you can purchase and maintain your own servers in your own data center (or use a non-cloud data center). This requires the most work on your part and tends to be the most expensive option, which is why so many companies are moving to the cloud.

As you can see by the above example, there are no answers that fit every scenario. You need to consider your needs, the available cloud services, and each category.

Keep in mind that you can split your application into multiple services and deploy some as SAAS, some as PAAS, and some as IAAS. Doing this requires that your application is divided into component services that can be easily split.

If that is not the case, be aware that you can change your cloud deployment over time. For example, you may choose initially to "lift and shift" an on-premises application - that is, move it from a local server to a Virtual Machine in the cloud. Over time, you can refactor your code, dividing your application into smaller services that can be deployed as PAAS services. This should reduce the amount of code you need to maintain and reduce your costs.

Generally speaking, you should avoid "reinventing the wheel". Take advantage of work that has already been done. And take advantage of services that do things not part of your core business. Every hour you spend patching an O/S, installing a software update, and replacing hardware is an hour that you are not spending enhancing and refining your core business logic.

Episode 700

A Celebration of Friends!

At the end of each Technology and Friends episode, I ask my guests to say something that included the words "Technology" and "Friends". Here is a compilation of all their responses from the last 99 episodes!

Todd Rundgren, Daryl Hall, and their music were a big part of my life growing up. I saw Rundgren perform at a small club in Newport, KY almost 20 years ago; but I had never seen Hall in concert until Friday evening at the Auditorium Theatre.

Rundgren began the evening, performing for over an hour. He played his biggest hits - "Hello, It's Me", "I Saw the Light", "It Wouldn't Have Made Any Difference", and "We Gotta Get You a Woman", along with some deeper cuts from his five-decade recording career. He also delivered moving renditions of two Motown classics - Smokey Robinson's "Ooh Baby Baby" and Marvin Gaye's "I Want You".

After a brief intermission, Daryl Hall took the stage and brought his energy to a mix of originals from his solo career and songs made famous by other artists. He drew the biggest cheers while performing the music of "Hall & Oates" - a dynamic duo that cranked out hit after hit in the 70s and 80s.

For the encore, Rundgren joined Hall on stage, where they sang together for several songs.

Both bands shared the same backing band - an unusual arrangement for a main act and warmup act. The band was electric - especially the saxophone player, who excited the crowd with his solos. Hall is still a known commodity to mainstream audiences, thanks to his performances on his long-running online show "Daryl's House". He tried to model the stage after the show’s set and kept the atmosphere as relaxed as the show with casual banter between songs. Rundgren still tours and occasionally records but has not maintained the strong public presence of Hall.

Hall and Rundgren are now in their mid-70s, and it is surprising how well their voices have held up. Hall was most famous for his range while singing the soulful melodies as the lead vocalist of Hall & Oates, but Rundgren has always shown great vocal range as well. The years have done little to diminish these skills.

The relationship between these two men goes far back. They both grew up in Philadelphia, they have recorded and toured together before, and Rundgren produced one of H&O's albums. Their closeness was apparent as they harmonized on stage.

3/7
Today I am grateful to see "The Batman" at an IMAX theater yesterday.

3/8
Today I am grateful for a new shower curtain.

3/9
Today, I am grateful for an Indian lunch this week, courtesy of my employer.

3/10
Today I am grateful for dozens of new Twitter followers this week.

3/11
Today I am grateful for a decent sleep 3 nights in a row.

3/12
Today I am grateful to see a live performance of "West Side Story" in Lincolnshire last night.

3/13
Today I am grateful my flight arrived safely, even if it was 24 hours later than planned.

3/14
Today I am grateful for:
-Lunch yesterday with Stephen and Patrice
-My first visit to Staten Island
-An exciting Islanders-Ducks hockey game last night

3/15
Today I am grateful for an evening playing Top Golf in New Jersey

3/16
Today I am grateful to meet my teammates in person this week after working with them virtually for months.

3/17
Today I am grateful for 3 days in New York and New Jersey

3/18
Today I am grateful for an uneventful flight to Florida last night.

3/19
Today I am grateful for a day with new friends.

3/20
Today I am grateful for my first visit to the Everglades yesterday.

3/21
Today I am grateful for a visit to the Naples Botanical Garden yesterday.

3/22
Today I am grateful for the generosity and hospitality of Sean and Emilie

3/23
Today I am grateful for people who care about me.

3/24
Today I am grateful that my co-worker wasn't upset that I overslept and showed up 15 minutes late for our meeting yesterday morning.

3/25
Today I am grateful to finish preparing my taxes.

3/26
Today I am grateful to see Joseph in concert last night

3/27
Today I am grateful for brunch with friends in Wicker Park yesterday.

3/28
Today I am grateful for new slippers

3/29
Today I am grateful to work from the local Microsoft office for the first time in over 2 years.

3/30
Today I am grateful to receive a care package filled with nuts from my employer.

3/31
Today I  am grateful for dinner with my sons last night

4/1
Today I am grateful that Americans are focused on the world's most important issues, like: who was the biggest jerk at the Oscars

4/2
Today I am grateful to see Daryl Hall and Todd Rundgren at the Auditorium Theatre last night - my first concert at that venue.

4/3
Today I am grateful for exciting basketball games.

Episode 699

Jean Lange on the History of JavaScript

Jean Lange details how JavaScript grew from a scripting language to the language of the web and how studying its history helped her to make better technology choices.