Episode 710
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/
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.
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:
"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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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".
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.
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.
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.
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.
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:
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.
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.
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.
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:
A good code review will accomplish the following:
Let's discuss each of these goals.
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.
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.
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.
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.
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.
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.
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)
"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.
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.
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
Introducing Cognitive Services and Computer Vision
Creating Applications with the Analyze Image Cognitive Services API
Handwriting OCR with Cognitive Services
Cognitive Services Text Recognition service
Text Recognition Cognitive Service with Binary Images
Sentiment Analysis Cognitive Service
Sentiment Analysis JavaScript Demo
Using the Video Indexer AI Tool
Sam Nasr on Cognitive Services
Martin Kearn on Document Recognition and Knowledge Extraction
Hamayal Choudhry and Samin Khan on SmartArm
"Building and Training your own Custom Image Recognition AI" presentation at NDC-Oslo
Talking about Cognitive Services on the Eat Sleep Code podcast
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:
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.
https://github.com/FlaUI/FlaUI
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.
https://docs.microsoft.com/azure/architecture/framework/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.
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 (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 (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.
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.
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
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.
It is unusual for a singer to warm up for her own band; but that is what Natalie Schepman did Friday night at the Old Town School of Folk Music. Schepman is one-third of Joseph - a vocal group from Oregon consisting of her and her two sisters: twins Allison and Meegan Closner.
Natalie had a solo career prior to forming Joseph, so she performed songs from that era, accompanying herself on acoustic and electric guitar, before taking a short break and returning to the stage with her sisters.
Each of the three ladies took turns singing lead on their songs performed throughout their 90-minute set. Their voices are distinct from one another, but each of them possesses an impressive vocal range on their own and together their harmonies are amazing! The only accompaniment came from Natalie's guitar playing, but that was enough.
I learned when I arrived that the show was all-request - fans were encouraged to suggest songs on the group's website and they played only those suggested by the fans. Although I was unfamiliar with Joseph before attending the concert, the crowd was not. Many came wearing shirts with the band's logo and large numbers sang along to the songs. It was a fun atmosphere and at least two couples were inspired enough to get engaged during the concert.
I arrived curious and I came away a fan of this trio.
In the universe of Robert Jordan's epic "The Wheel of Time" series, events repeat themselves with each turn of time's wheel - A turn that lasts thousands of years and spans many ages. As the Wheel turns, people are reborn to fulfill a destiny predetermined in a previous age.
One such person was The Dragon - a man who wielded the power of the universe to defeat the forces of darkness but was driven mad by that power.
It is now thousands of years later, and prophecies have foretold the coming of a new Dragon. Rand al'Thor, the protagonist of "The Eye of the World", has wielded this same power to temporarily defeat the villain Ba'alzamon and he now realizes that he is the Dragon Reborn. Rand is a shepherd from an isolated village who is unprepared for this responsibility and fearful of the madness that may consume him.
"The Great Hunt" is volume 2 of tWoT series and takes us with Rand as he and his companions seek the Horn of Valere - a sacred artifact stolen by Dark friends from those who follow the Light.
As in tEotW, we follow the travelers on their quest as they battle magic, demons, and other obstacles until they conclude their quest. Along the way, we get a closer look into the characters that make up the series and the world they inhabit. They grow up a little, hone their skills a little, and evolve a little. The action comes swiftly, but the characters evolve slowly - presumably to make the arc last for over a dozen books in the series.
The pacing is better in this novel than in Book 1, which dragged at times. Topics introduced in the first novel are explored further in Book 2. We see rivalries between factions of the Ais Sedai - a cult of female warriors / sorceresses capable of channeling the universe's power. We see women betrayed and enslaved by other women; we see Perrin tapping into his power to communicate with wolves; and we see Mat bonding himself to more magical devices with tragic consequences.
Jordan continues to draw ideas from Tolkien (calling upon an army of ghosts to fight your battle is an idea lifted straight out of Lord of the Rings), but he includes more of his own ideas in this story.
This is a worthy sequel and an inspiration for me to continue to Book 3.
Episode 698
Godfrey Nolan has been building applications that access the power of drones. He explains the current and future practical uses of these applications and how to get started using SDKs from drone vendors.
https://riis.com
https://www.meetup.com/drone-software-meetup-group
So many of us try to do everything. When an opportunity presents itself, we take it. When someone asks us to do something, our first instinct is to say "yes".
Greg McKeown advises us against this. In his 2014 book "Essentialism: The Disciplined Pursuit of Less", he tells us to think before saying "yes" or taking on more than we can handle. We can simplify our lives by focusing our energy only on those things that bring the most rewards. By eliminating non-essential things from our lives, we can focus more on what we value most.
McKeown provides some practical advice on how to become more focused. He tells us to block off time for ourselves; to take time to consider what in our life is most important and what we can eliminate; to take care of our bodies by getting sufficient sleep; to recognize when things are going poorly and know when to step away; to build buffer time into our schedules; and to learn how to politely decline requests.
Essentialism seems like common sense, but we are all guilty of overextending ourselves at least some of the time. McKeown's advice is sound. When I sold my house and moved to a small apartment in Chicago 8 years ago, I was able to rid myself of a lot of physical clutter. But I am still burdened with mental clutter. I am among those who are easily distracted and stretched too thin. Prioritizing my life would add value to it; especially if I could drop those things at the bottom.