E13 Tech

Leadership - Validate Success Like You Validate Failure

2024-09-13T00:00:00Z

Leadership: Validate Success Like You Validate Failure

I recently watched a video where someone shared an experience working with a mining operation. A building caught on fire, and after they got it under control, the entire company shut down for 24 hours. Not to celebrate or recover from the fire, but to focus entirely on preventing it from happening again. This shutdown was taken seriously-they were validating what had gone wrong, figuring out the root cause, and taking steps to ensure it wouldn't repeat.

Now here's the kicker: just a month earlier, the same company had achieved one of the biggest goals in their history, but they didn't stop work for that. No 24-hour reflection, no pause to validate why things went so well. They simply celebrated and moved on.

This got me thinking: when something goes wrong, we pour energy into finding the root cause. We investigate what led to the issue and implement changes to prevent it from happening again. It's instinctive, especially in consulting, where a failure can mean losing a valuable client or having a contract canceled. But do we apply the same rigor when things go incredibly well?

Where's the Root Cause Analysis for Success?

Your team just executed the smoothest go-live in the firm's history. You secured the largest contract your company has ever landed and delivered on it flawlessly. But what happens next? Maybe a happy hour to celebrate, which is great, but are we stopping to validate why this success happened?

Just like we do with failures, shouldn't we pause to reflect on what made a success possible? After all, if we don't understand what made this outcome different, how can we ensure we replicate it in the future? It's not enough to just celebrate-we need to treat success as an opportunity to learn and improve.

Does this sound familiar? Maybe in Agile? Ever heard of a "Retrospective"?

In Agile, teams regularly hold retrospectives to analyze what went well and what didn't after each sprint. It's a core practice for continuous improvement. But what if we applied that same level of analysis to our most significant achievements? Obviously on a smaller scale, one of the points of agile sprints is to have a regular cadence of feedback and improvement.

After a major success, do we:

Investigate what was different this time?
Identify key decisions or strategies that contributed?
Understand why this project exceeded expectations?

By validating success the same way we validate failure, we can create a roadmap for replicating those positive outcomes.

What about your team?

When was the last time you did a root cause analysis for a success?
Have you found specific factors that contributed to a win that you can apply again?
How does your company handle major achievements, and is that enough to ensure future success?

Let me know your thoughts in the comments below-I'd love to hear how you and your teams reflect on and validate success!

GitHub Copilot - Automating Git Comments and PR Summaries

2024-09-12T00:00:00Z

GitHub Copilot? One Use Case That Pays for Itself

I've been using GitHub Copilot for several months now, and it's surprising to me how many times I've been asked, "Is it really worth the price?" or "Why would I pay for Copilot when I'm already paying high developer salaries?" These are fair questions, and I get where people are coming from. To answer those questions I thought I'd share a few examples of how in my normal workflow of writing code in Visual Studio for this blog site, Copilot has enabled me to include better summaries of changes in my Git commits and Pull Requests (PRs) without adding any extra time to my workflow.

If you're interested in more examples where GitHub Copilot proves its value, check out my other posts on GitHub Copilot where I dive into more practical use cases.

Why Source Control Commits Are Important But Overlooked

As developers, we all know how important it is to maintain good documentation and traceability in our source control history. The reality, especially for side projects such as this blog site, is that tasks like writing detailed commit messages or pull request summaries often fall by the wayside when we're trying to be productive. Sure, it's ideal to document every little detail, but how many times have you found yourself on a project with tight deadlines and budgets rushing to finish a task at 4:45 on a Friday and feeling pressured to skipp the extra effort of writing meaningful comments because "it doesn't really matter". Or maybe even worse it's a requirement for you to have this level of detail and if you don't get it in quickly you could be the one to cause a feature to miss being included in a release because of a source control comment being late, not detailed enough, inaccurate?

Here's where GitHub Copilot can be a game changer. By automating the process of generating detailed commit messages and PR summaries, it allows you to improve traceability without sacrificing time. And while this might seem like saving a few minutes here and there, the long-term impact is significant-especially when you need to revisit code six months or two years later. And before you respond "there are already tools that help with this today" that is true, but the value to me in CoPilot is it's attempt to interpret what I was doing based on the change and describing it. Is it worth the price? Let's dive into a couple of simple examples from my experience working on this blog site to see this in action.

Commit Messages

While creating a recent post, I decided to update some NuGet dependencies in the .csproj file to address vulnerability warnings. These weren't critical for my setup-since my C# console app only runs within a GitHub Action to generate static content for my site-but it was still a best practice that I should get around to sooner than later.
Normally, in cases like this, I would type a quick commit message like "updated NuGet references to address vulnerability warnings." Sure, all developers should include more detailed explanations, but let's be honest: business stakeholders rarely care about the level of detail in a git commit.

With GitHub Copilot, though, I was able to generate a much more detailed commit message in seconds. Copilot captured not just the fact that I updated packages but also listed the specific packages and the versions I upgraded to:

This level of detail is more than I would normally provide, but since it was auto-generated, it was easy to include. And, as a solo committer on this project, this could be a crucial reference point for future me to understand exactly what was changed in the event of an issue or follow-up task. In fact I'd normallly avoid including this level of detail because I don't want to risk a typo and have the comment not match the actual changes, automating it gives me confidence that it is correct (and even if I don't believe it it's really easy to compare the comment to the source file and manually verify).

Pull Request Summaries

Following that example I included that commit in a PR along with the content for a new blog post, titled "Be the Idiot". I normally try to take a few minutes to document what is in a Pull Request especialy when I'm included an unrelated, especially when I'm including a change thats unrelated to the main content. In reality - I'm rarely as detailed in my PR summaries as I probably should be unless it's an organizational requirement, what value does my PR summary have to the business?

Here's where GitHub Copilot comes in to help me out. As shown in the screenshot, Copilot auto-generated a detailed PR summary for me, breaking down each change by file:

It isn't perfect but that is a lot of great detail that I would normally skip over. I can quickly add some context to the summary to outline the purpose that cannot be inferred from the changes alone and move on. In my opinion CoPilot has summarized the details that do not need to be included in the PR summary but included details that I'd usually skip over because I don't want to take the time to document them.

This might sound like I'm being lazy but in reality, I'm trying to balance the time I spend on tasks that provide value to the business (my desire to get blog content out to the likes of you) and tasks that I could do better but don't provide value. Apply this example to a complex solution that you are developing in, where you have multiple developers working on the same codebase, and the value of this level of detail in the PR summary becomes even more important. Have you ever needed to make a sweeping change across 50 or even 100+ files? How much time would it take you to document each change in a PR summary? Copilot's ability to assist in reviewing and documenting each change and summarizing for you could provide real time savings.

Another benefit of this level of automated details is reminding me what is included in the PR. Sure I have the list of files in there but what if I made multiple changes in the file for different reasons? I've had CoPilot summarize what it thought was done in a file and make me realize that I had accidentally forgotten to remove some test code in a file that I was experimenting with. I would have caught it in my own testing of the PR when I did my final validation but the sooner you find things like this the faster they are to address.

Conclusion

Yes, we're talking about a few minutes here, a few minutes there. So, I get where the arguments come from-"How much time am I really saving?" But think about this: In the past, I've often grouped changes together in GIT or PR commits that weren't strictly related because of looming deadlines, especially when every minute counts-like 4:45 on a Friday afternoon.
The real value becomes clear when reviewing changes in the future-two years down the line, staring at a commit history and asking, "Okay, JJ, what were you thinking?" In those moments, detailed commit messages and PR summaries become priceless, and GitHub Copilot is helping me ensure I don't cut corners, even when under pressure.
Some might argue that Copilot enables developers to be lazy, and sure, that's a risk with any Gen AI tool if you're the type to blindly accept whatever it gives you. But I believe the best devs will use tools like this to focus on what really matters: freeing them up to provid business value by not wasting time on tasks that can be automated.

At the time of this post, GitHub Copilot is priced at $10 per month for individuals or $100 per year. For businesses, it's $19 per user, per month, and $39 per user for enterprise plans, depending on organization size.

Is it worth it? For me personally absolutely-especially when it means painlessly automating what most would argue is a best practice. Is it worth it for you and/or your team? If you are developing w/in Visual Studio or any other IDE that applies CoPilot in this way then I feel like this alone is worth the price of admission but I'd love to hear your thoughts.

Do you use GitHub Copilot today? Do you feel like it's worth the price? And if you're already using it, what's your favorite use case where you've seen it pay for itself? If not, what's holding you back? Comment below and let's start a conversation!

Leadership - Be the Idiot

2024-09-11T00:00:00Z

Be the Idiot: Why Leaders Shouldn't Be Afraid to Ask Questions

In a YouTube short titled "Be the Idiot," Simon Sinek shares a simple yet powerful piece of advice: don't be afraid to ask questions. This resonates with me because, as someone who's often in a leadership role on development projects, I'm often expected to be the "expert". But let's face it-no one can know everything, especially in the constantly evolving world of technology.

As Master Yoda once wisely said, "Much to learn, you still have." Even the greatest Jedi can't know everything, and asking questions is part of the journey toward mastery. No shame in asking a few clarifying questions along the way, even if it makes you feel a bit like a youngling.

Asking Questions Doesn't Make You Less of a Leader

I've been in consulting for a long time, and it's given me the opportunity to work across many industries, technologies, and client types. Each one comes with its own unique challenges and learning curves. Whether it's a new industry regulation, an unfamiliar tech stack, or a unique integration challenge, asking questions is not only important-it's critical.

As a leader, I've found that some people fear asking questions because they believe it undermines their authority. I couldn't disagree more. In fact, asking clarifying questions often fosters a stronger connection with your team and clients. It shows you're engaged, focused on understanding the problem, and ready to collaborate for the best solution.

Or as Obi-Wan Kenobi might say, "Who's the more foolish? The fool, or the fool who follows him?" Not asking questions could make you the second fool. So go ahead-be the first fool and ask that question.

Not only that-if you have a question, chances are someone else also has the same question but might be afraid to bring it up. By being comfortable enough to ask what seems like a dumb question, you might encourage others to ask great clarifying questions that you hadn't even considered. This can open the door to deeper insights and better solutions for everyone.

The Consulting World is Always Changing

One of the reasons I've never hesitated to ask questions is that in consulting, you're never working in a bubble. Industries shift, technology evolves, and there's always something new to learn. Over the years, I've dealt with countless combinations of industries and technologies. The only constant is change, and no matter how much experience you have, keeping up with it all is impossible without being open to learning and admitting when you don't know something.

In fact, the faster you can ask a question, the faster you get to the right solution. It might seem obvious, but so many people are hesitant to admit they don't have all the answers.

Conclusion: Being the Expert Means Being Curious

If there's one takeaway from the "Be the Idiot" mindset, it's this: expertise isn't just about what you know-it's about your willingness to keep learning. As the Chinese proverb goes, "A man who asks is a fool for five minutes. A man who never asks is a fool for life." Don't let the fear of appearing like an "idiot" stop you from doing your best work. After all, the smartest people are often the ones who ask the most questions.

What do you think?

Have you ever been in a situation where asking a "dumb" question led to a breakthrough?
As a leader or team member, how do you encourage a culture of curiosity and learning on your projects?
What's one question you've been hesitant to ask in a professional setting?

Drop your thoughts in the comments below-I'd love to hear about your experiences and how you handle these moments of uncertainty!

EF Core - More Intuitive Exceptions

2024-09-09T00:00:00Z

Handling EF Core Exceptions Gracefully: A Cleaner Approach with EntityFramework.Exceptions

While scrolling through my YouTube feed, a video titled "Stop Dealing with EF Core Exceptions Wrong!" caught my attention. It highlighted an issue I've seen far too often in projects-overcomplicating our solutions to handle specific errors that seem unavoidable. It's something I've dealt with frequently when working with EF Core.

One key frustration is dealing with SQL Server error codes in Entity Framework. When an exception arises, you're often forced to dig into specific error codes, writing redundant and bloated error-handling logic. This not only clutters your codebase but also increases the risk of missing or improperly handling certain cases.

The good news is there's a better way.

The Problem: Handling SQL Server Errors Manually

Let's take an example from the excellent post over at Giorgi's blog. Giorgi demonstrates the approach I've used in the past to use SQL Server error error codes when I had specific handling to be done. Imagine something like this:

try
{
    // Code that may throw an exception, like saving to the database
    context.SaveChanges();
}
catch (SqlException ex) when (ex.Number == 2627) // Violation of unique constraint
{
    // Handle the specific exception, maybe log it or show user-friendly message
    Console.WriteLine("A duplicate entry exists.");
}
catch (SqlException ex) when (ex.Number == 547) // Foreign key violation
{
    // Handle foreign key constraint violation
    Console.WriteLine("You cannot delete this record as it is referenced elsewhere.");
}
catch (SqlException ex) when (ex.Number == 2601) // Another form of unique constraint violation
{
    // Handle another case of duplicate entry
    Console.WriteLine("Duplicate record found.");
}

This approach works, but it's not clean. You have to track each error code manually, and your error handling can easily spiral out of control as your project grows.

The Cleaner Solution: EntityFramework.Exceptions

EntityFramework.Exceptions is a package that simplifies the entire process, allowing us to focus more on writing meaningful, maintainable code instead of error-handling boilerplate.

With this package, the tedious manual checks for error codes are abstracted away. The library catches common database-related exceptions and converts them into more specific .NET exceptions that you can handle gracefully. Here's an example of how you can clean up the error-handling process:

Implementing EntityFramework.Exceptions First, you'll need to install the package. In my case I'll use the SqlServer version, just make sure you choose the correct package for your database type:

dotnet add package EntityFramework.Exceptions.SqlServer

Then, update your DbContext to configure it with EntityFramework.Exceptions. This snippet is taken from a Program.cs where I am configuring a ServiceCollection to inject MyDbContext as needed:

var serviceProvider = new ServiceCollection()
	.AddDbContext<MyDbContext>(options =>
	{
		options.UseSqlServer("connection string");
		options.UseExceptionProcessor();
	})
	.BuildServiceProvider();

Now, your error-handling code becomes much cleaner:

try
{
    // Save changes without manually checking for specific SQL error codes
    context.SaveChanges();
}
catch (UniqueConstraintException ex)
{
    Console.WriteLine("A duplicate entry exists.");
}
catch (ReferenceConstraintException ex)
{
    Console.WriteLine("You cannot delete this record as it is referenced elsewhere.");
}

No more manually sifting through error codes; the package does all the heavy lifting for you, making your code much cleaner and easier to maintain.

And possibly more important, this exception handling code is not specific to SqlServer anymore. If you decide to switch to a different database provider or you want to share your code with another team that is using a different database, you won't need to change your error handling code. This may not be a concern for every team but if it is then this is a huge win for maintainability, shareability, and future-proofing your code.

The Trade-Off: Replacing Standard Exception Handling

One caution however, this package effectively replaces the standard exception handling in EF Core, so you'll need to ensure you're comfortable with the trade-offs. For example you probably do not want to implement in a large existing codebase that is already coded to handle direct error codes, save this for the next new project or major rewrite that warrants the effort. As much as I am looking forward to using this package in my next project, I will be cautious to ensure that the team is aware of the change and that we are all comfortable with the new approach.

Conclusion: Writing Cleaner Code Together

This is far from a new package and I wish I had run across it sooner. This will help me drastically reduce the amount of error-handling boilerplate in my projects and make the code more intuitive to read without an over abundance of line comments to explain what the codes mean for the next dev, it's an elegant solution that helps you write code that is more intuitive and cleaner over all.

What about you? Have you run into similar frustrations with EF Core exception handling in your projects? Will you start using EntityFramework.Exceptions, or do you already have a different go-to package? Let's write cleaner, more maintainable code together-share your thoughts in the comments below!

Leadership - Tackle the Monkey First

2024-09-05T00:00:00Z

This YouTube short was recently shared with me (thanks Frank!), and it brought up a common issue we often face in projects. Stakeholders often prefer to focus on visible wins-what this clip refers to as "the pedestal"-that show immediate progress but often neglect the riskier, foundational work, the "monkey" that needs taming.

So how can we, as the leadership of our teams, avoid falling into this trap?

The Pedestal Trap

We've all been on projects where the pressure is on for the "quick win," the demo, or that flashy feature that can impress stakeholders. The problem is, while everyone's focused on delivering something that looks great on the surface, the real challenges-what I'll call "the monkeys"-are sitting in the background, getting ignored.

These are things like that key system integration no one has ever done before, and the team isn't even sure is possible, or that compliance requirement that has shut down countless projects because it wasn't considered from the start. Maybe it's a legacy system that needs modernization but is too risky to touch, or a security flaw that everyone knows about but doesn't want to deal with because it's not "urgent" enough-or is not visible enough, so stakeholders want to defer it to the end.

Yup, you know those projects. Sure, we got some quick wins that looked great on the surface, but no one was tackling the real problems-unstable architecture, mounting technical debt, and all the risky stuff lurking under the radar. Fast forward a few months, and everything came crashing down. By then, leadership had moved on to the next shiny thing, leaving the dev team to clean up the mess.

The Balance: Pedestal and Monkey

It's tempting to focus on the flashy stuff-the features that grab attention and make stakeholders feel like the project is moving forward. But you can't afford to ignore the risky, foundational work that keeps everything stable. Yes, building the pedestal has its place. Stakeholders need to see progress, and sometimes that visible momentum is what helps secure buy-in and keep the project on track. But that doesn't mean you can keep pushing off the critical tasks-the "monkeys."

As leads of our dev teams, we have a responsibility to guide and advise stakeholders and management. It's up to us to help them see the importance of addressing those foundational risks early on. A successful project strikes a balance between the two: delivering visible progress to maintain confidence, while actively working on the behind-the-scenes tasks that ensure long-term success. It's not about choosing one over the other, but about making sure both are addressed at the right time. Focusing too much on the pedestal will make everything come crashing down when the core issues surface.

Avoiding the Pitfall

So how do you avoid this trap? Don't just chase the visible wins. Yes, sometimes you need to build the pedestal to show stakeholders things are moving forward-but be transparent about the monkeys. Stakeholders would much rather hear upfront about the challenges you're tackling than be blindsided later by a crisis.

I'm not going to say it'll be easy. Depending on how experienced your stakeholders are and how much pressure they're under to produce results, these conversations might be incredibly painful. But as dev leaders, it's our responsibility to be upfront and guide them through these decisions. By tackling the risky, critical work early and keeping stakeholders informed, you're setting the project up for long-term success, even if it requires tough conversations along the way.

Ask yourself in your next planning session:

What risky tasks are we avoiding?
Are we chasing short-term wins that will hurt us long-term?
How can we balance showing progress with solving core issues the team clearly sees?

Focus on taming the monkey before the pedestal is complete, and make sure your stakeholders are along for the ride, knowing what to expect. You'll be glad you did when the project is a success, and you have a well trained Monkey sitting on top of that beautiful Pedestal.

Have you seen this pattern before in your projects? How have you balanced quick wins with addressing risky challenges? What other obstacles have you encountered along the way? Comment below and share your experiences-I'd love to hear your insights!

Deploying Statiq to Azure Static Web App

2020-12-01T00:00:00Z

Statiq is a static content generator written in C# that is used to generate the site you are reading right now. It is an incredibly robust and feature full project, Below is a series of steps that you can walk through to create your own blog similar to this one.

The source for the app that generates this site is open source at https://github.com/e13tech/blog. Feel free to browse the source and get inspiration for your own project.

Deploy to Azure Static Web App using Github Actions

Static Web Apps is an offering in Azure that is currently in preview that streamlines the deployment of applications from GitHub. It has a few limitations in preview but being able to quickly setup

Create new Static Web App resource in the Azure Portal

Note this is still in preview so it may not be ideal for widespread production use however while it is in preview having a platform to host a static site with a custom domain over https for free is an incredible value.
Enter the details to your github repository

The important details here are using the Custom Build Preset with the App location of output. For Statiq there is no need for an Api or App artifact location so clear those out. However being able to tie the deployment of an Api as an Azure Function opens up some incredible opportunities for expanding to a more dynamic solution.
Wait for the resource to be created

I don't normally document wait steps but this one is important. As part of the resource creation a new GitHub workflow will be created in the branch specific at creation time complete with the secrets to access the newly created resource. Once you have verified that the GitHub workflow has been created successfully then we can modify it.

Update the auto generated workflow yml to run the Statiq console app and produce the output that will actually get published to Azure. Note: do not attempt to rename the file because the created azure resource refers to it for some of it's functionality.

name: Azure Static Web Apps CI/CD

on:
  pull_request:
  types: [opened, synchronize, reopened, closed]
  branches: [main]

jobs:
 build:
    if: github.event_name == 'push' || (github.event_name == 'pull_request' && github.event.action != 'closed')
    runs-on: ubuntu-latest
    name: Build And Update Pull Request

    steps:
    - uses: actions/checkout@v2
    - uses: actions/setup-dotnet@v1
      with:
        dotnet-version: 5.0.100
    - run: dotnet restore
    - run: dotnet build --configuration Release --no-restore
    - run: dotnet run --output output
    - name: Build And Deploy
      id: builddeploy
      uses: Azure/static-web-apps-deploy@v0.0.1-preview
      with:
        azure_static_web_apps_api_token: ${{ secrets.AZURE_STATIC_WEB_APPS_API_TOKEN_... }}
        repo_token: ${{ secrets.GITHUB_TOKEN }}
        action: "upload"
        app_location: "output" # App source code path
        api_location: "" # Api source code path - optional
        output_location: "" # Built app content directory - optional

close_pull_request_job:
  if: github.event_name == 'pull_request' && github.event.action == 'closed'
  runs-on: ubuntu-latest
  name: Close Pull Request Job
  steps:
    - name: Close Pull Request
      id: closepullrequest
      uses: Azure/static-web-apps-deploy@v0.0.1-preview
      with:
        azure_static_web_apps_api_token: ${{ secrets.AZURE_STATIC_WEB_APPS_API_TOKEN_... }}
        action: "close"

This is a large file but my changes can be broken down into a few segments

[1] : Keep the workflow name the auto-generated one because there is a link w/in Azure that is looking specifically for that
[3-6] : Setup a trigger on pull requests going into the main branch. My preference is to have feature branches for my blog articles and to create a PR for each into main branch while I work on them.
[14-21] : The series of standard steps that prepares a .NET 5 environment
- [21] : Run the console app directing the generated content to an output directory
[22-31] : The original step that was generated by Azure to do the actual publish
- [29] : app_location needs to match the same path that was used on [24], in this example output
- [30,31] : api_location and output_location are not required for this Statiq example but ensure they are left blank
[33-43] : This job triggers on the closure of a pull request to clean up the staging url that can be used to preview the output of a branch that is still in development
[26,42] : These lines point to the secret that is generated in the github repository, this name will be uniquely generated and set to your application

Recap

Now even though it was not defined as a template originally we are able streamline the process of developing content using Statiq and having it automatically deploy to Azure. The best part of this workflow is that I can create a branch for each topic that I am beginning blogs on and as long as there is an open pull request attached to the branch then the github action will create a unique url. This allows you to share that url with anyone to review the actual generated content exactly as it would in production, and once the PR is merged and accepted no additional steps are required in order to publish to production.

This is convenient for a personal blog like this so I can loop in colleagues for help proofing a post before it's done. You can probably also see how beneficial this could be for a corporate blog or anywhere that content needs to be reviewed or approved. Setting up a CI/CD flow is usually more complex involving setting up environments, approval processes, etc. Microsoft has done a fantastic job creating this offering and especially while it's in preview you'd be hard pressed to find a more appealing option while it is free to use.

What kind of projects will you setup using this workflow? What adjustments will you make to improve it? Share with others in the comments below!

Special Thanks to Antonino Visalli on Unsplashfor the photo that was used in this post

Blog using Statiq - Getting Started

2020-11-01T00:00:00Z

Statiq is a static content generator written in c# that is used to generate the site you are reading right now. It is an incredibly robust and feature full project, Below is a series of steps that you can walk through to create your own blog similar to this one.

The source for the app that generates this site is open source at https://github.com/e13tech/blog. Feel free to browse the source and get inspiration for your own project.

Create a new .NET console app and add the Statiq.Web Package
```
dotnet new console --name AwesomeBlog
cd AwesomeBlog
dotnet add package Statiq.Web --version 1.0.0-beta.13
md input
md theme\input
```
Most of this is fairly intuitive but in case you need some more details
- [1] : Create a .NET console app that will be the generator for your site
- [2] : Navigate into the directory for your new console app
- [3] : Add the Statiq.Web nuget package, at the time of writing this Statiq is still prerelease so specify the version
- [4] : Create the input directory that will host
- [5] : Create the theme input directory that will contain the layout and other site assets
Create a bootstrapper Program.cs
```
using System.Threading.Tasks;
using Statiq.App;
using Statiq.Web;

namespace Your.AwesomeBlog
{
  public class Program
  {
    public static async Task<int> Main(string[] args) =>
      await Bootstrapper
        .Factory
        .CreateWeb(args)
        .RunAsync();
  }
}
```
A very straight forward Program.cs, notable lines:
- [2] : The core Statiq framework namespace with the original Bootstrapper.Factory comes from
- [3] : The Statiq Web namespace which provides the .CreateWeb(..)
- [9-13] : Have the Main(string[]) method await the call to the Statiq
Create a new index.md file within the input directory with the following content
```
Title: My First Statiq page
---
# Hello World!

Hello from my first Statiq page.
```
There are countless great sources online explaining how Markdown works including the official Statiq website. In a follow-up post I will go through an example of how I am utilizing this input files.
Launch the built-in previewer from a terminal window
```
dotnet run -- preview
```
If all went well Statiq will display a bunch of diagnostic information and then host your new site at https://localhost:5080 with livereload meaning that you can edit your site content in your favorite editor such as VS Code and the browser will reload to display your changes as you save.

Most of these steps here are borrowed directly from the Statiq Quick Start and adjusted for my content. Combining Clean Blog Template with a responsive web template such as one from as a starting point will get you most of the way towards having a blog of your own, lets look at some of the modifications I made beyond this.

Statiq Web is built on top of Statiq Framework and this series covers a small fraction of the functionality of this fantastic project. So far I am very happy with this platform and am anticipating the release of Statiq Docs which is built on top of the Statiq Web with a focus on generating .NET API documentation.

What static content generator have you used? Do you have a blog of your own that's statically generated? Share your experiences in the comments below.

Special Thanks to Philipp Katzenberger on Unsplash for the photo used for this post

Fun with Windows Terminal - Roaming Profiles

2020-04-04T00:00:00Z

Clearly I'm a big fan of the Windows Terminal but what i'm not a huge fan of is repeating myself. As a consultant at any point in time I may have several different computers to work with and although the steps aren't terribly complicated it can be frustrating to try and keep multiple terminal profiles synchronized across several different computers. In addition to synchronization of the profiles it also seemed like others may enjoy seeing what I have configured to start their own setup from here, so enter my Github terminal repository.

The easy part of the equation was using Github, a public vehicle for sharing code with the world but getting the settings out of the default user profile directories wasn't quite as straight forward. One requirement I had was a fairly dummy-proof way of syncing everything up without trying to remember what I changed, where the change was, and when I applied changes last if it's a system I don't use regularly.

Here are the scripts that I came up with, you can find these along with the icons and backgrounds at my terminal github repository.

Clone Repo locally

cd c:\_
md c:\_\_terminal
git clone https://github.com/jjbussert/terminal _terminal
cd c:\_\_terminal

This needs to be done once, feel free to clone mine directly or copy/fork what I started to make your own!

hardlinks.ps1

if(Test-Path Microsoft.PowerShell_profile.ps1) 
{ 
   Remove-Item Microsoft.PowerShell_profile.ps1 
}
New-Item `
   -Name Microsoft.PowerShell_profile.ps1 `
   -ItemType HardLink `
   -Value $env:HOME\Documents\Powershell\Microsoft.PowerShell_profile.ps1 

if(Test-Path profiles.json) 
{ 
   Remove-Item profiles.json 
}
New-Item `
   -Name profiles.json `
   -ItemType HardLink `
   -Value $env:HOME\AppData\Local\Packages\Microsoft.WindowsTerminal_*\LocalState\profiles.json

[1-3 & 10-12] : There are two files that we want to synchronize on our host system, these 2 if blocks will remove the files and setup hard links to those files in their locations in the $env:HOME directory where the shells expect them to be
[5-8] : This is the profile configuration of powershell core
[14-17] : this is the json containing the profiles for Windows Terminal itself

The key consideration for this script is to be able to execute it and either initialize the environment or upgrade it if this has already been run before. This script sets up hard links to the key files if they haven't already been setup, this way I can use git to synchronize files involved.

Conclusion

And that's it! Now keeping multiple system profiles in sync is a simple as a git pull just like you are likely already using in your day to day work. These steps are specifically about the host Windows system but you can easily do something similar for the WSL distros to sync the .bashrc files.

So what do you think of the repository for my Windows Terminal setup? Did you copy/clone your own? What adjustments did you make to your setup? Share in the comments below!

Special thanks to Luca Bravo for the photo used in this post!

Fun with Windows Terminal - WSL / Kali

2020-04-03T00:00:00Z

Previously I explained how to get started with windows terminal by setting up PowerShell Core as the default profile, Next I setup Ubuntu as my first WSL (Windows Subsystem for Linux) distro but why stop there? Next we'll go through setting up Kali, a Linux distro known for being designed for digital forensics and penetration testing (aka a heavy focus on digital security scenarios which is why I like having access to it).

For this post I'll assume that you have already setup Ubuntu or another WSL distro to look at how easy it is to add additional distros once the pre-reqs have been completed for another.

If you want to use the same icons and backgrounds as me you can find them in my terminal github repository where I sync my setup to.

Go to the Microsoft App Store > Search for "WSL"
For this walkthrough choose Kali
Kali is now ready to finish setting up The steps are intuitive, last one being setting up a username for yourself in this distro

Launch Windows Terminal and execute code $settings > this will bring up VS Code with the Windows Terminal profile.json in it, look for a section with commandline="Windows.Terminal.Wsl" and name="Kali" and update it like below.

{
  "$schema": "https://aka.ms/terminal-profiles-schema",

  "defaultProfile": "{61c54bbd-c2c6-5271-96e7-009a87ff44bb}",

  "profiles":
  {
      "defaults":
      {
          "fontFace":"Delugia Nerd Font",
          "acrylicOpacity": 0.8,
          "useAcrylic": true,
          "startingDirectory": "C:\\_"
      },
      "list":
      [
          ...
          {
              "guid": "{46ca431a-3a87-5fb3-83cd-11ececc031d2}",
              "hidden": false,
              "name": "kali",
              "source": "Windows.Terminal.Wsl",
              "backgroundImage": "C:\\_\\_terminal\\kali.png",
              "backgroundImageOpacity": 0.3,
              "backgroundImageAlignment": "bottomRight",
              "backgroundImageStretchMode": "none",
              "icon": "C:\\_\\_terminal\\icon-kali.png"
          },
          ...
      ]
  },

  ...
}

Mostly repeated from part 1, let's look at the important sections:

[8-14] : For me I wanted to have some settings the same across profiles such as font and starting directory
[19-27] : In order to more easily identify the terminal type (but mostly because it's fun) I've updated the profile with and icon and background image.

Now in Windows terminal you should see Kali as an option for a new tab and you should see something like this: And as great as this is, we can do better so lets add powerline
Execute the following in the new Kali terminal
```
sudo apt-get update 

sudo apt install golang-go
sudo apt install git
go get -u github.com/justjanne/powerline-go
```
- [1] : This will update the package repository cache, only needed for an initial install
- [3-5] : Installs Go, Git, and uses them to install powerline-go
Execute code ~/.bashrc and add the following to the bottom
```
GOPATH=$HOME/go
function _update_ps1() {
    PS1="$($GOPATH/bin/powerline-go -modules nix-shell,venv,ssh,cwd,perms,git,hg,jobs,exit,root,vgo -error $?)"
}
if [ "$TERM" != "linux" ] && [ -f "$GOPATH/bin/powerline-go" ]; then
    PROMPT_COMMAND="_update_ps1; $PROMPT_COMMAND"
fi
```
Similar to the Ubuntu post the WSL Kali distro includes the code command for downloading and installing the VSCode server to seamlessly execute VSCode installed on your local machine.

Adding these lines will enable powerline-go as part of bash. One tweak I made to this code taken from the powerline-go installation page was changing the list of default modules being loaded on line [3] to remove the username@computer from the powerline.

If you compare my Ubuntu and Kali posts you'll see that the process is nearly identical, a slight tweak to the steps to install git because Kali doesn't come with it by default and you end up with the same result. Clearly overkill but if you have penetration tests or any other security related scripts that you sync to a git repo it may be convenient to setup powerline like I have here. You can see below a screenshot of the final result.

What do you think of WSL running Kali via Windows Terminal? What is your linux distro of choice? What different customizations did you make? Share in the comments below?

Special thanks to blurrystock for the photo used in this post!

Fun with Windows Terminal - Getting Started

2024-09-12T00:00:00Z

For those of you that have yet to hear about the new Windows Terminal I have to ask "have you been living under a rock?". Joking aside when Microsoft first announced their new open source terminal many of my colleagues were left asking why? Many of them have already found alternatives to the ancient cmd.exe console that's been shipping with windows since the beginning of time and most have already found their preferred alternative applications. Being a Microsoft fanboy these days I was excited by the

One of the key aspects of Windows Terminal that got me excited was how easy it was to customize and the degree to which I could do it. Certainly not as much as downloading the code and building my own custom version (which there are very interesting write-ups of people doing exactly for some fascinating results). The provided profile customizations combined with some custom work the community has already done makes it so simple to do. But I'm getting ahead of myself, let's take a look at how you can get started with Windows Terminal and how easy it is to make some impressive looking tweaks. Below is everything you'll need to follow along with the rest of this series, I'm going out of my way to do everything via a CLI even if there is a UI path as well.

If you want to use the same icons and backgrounds as me you can find them in my terminal github repository where I sync my setup to.

Go to the Microsoft App Store > search for "Windows Terminal"

Execute the follow powershell commands from an elevated terminal

Set-ExecutionPolicy Bypass -Scope Process -Force; `
    [System.Net.ServicePointManager]::SecurityProtocol = `
    [System.Net.ServicePointManager]::SecurityProtocol -bor 3072; `
    iex ((New-Object System.Net.WebClient).DownloadString('https://chocolatey.org/install.ps1'))

choco upgrade dotnetcore-sdk -y
choco upgrade git -y

dotnet tool update --global PowerShell

Install-PackageProvider -Name NuGet -Force
Install-Module posh-git -Scope CurrentUser -Force -SkipPublisherCheck
Install-Module oh-my-posh -Scope CurrentUser -Force -SkipPublisherCheck
Install-Module PSReadLine -Scope CurrentUser -Force -SkipPublisherCheck

There's a lot in here so lets break it down

[1-4] : Chocolatey is a package manager for Windows that makes it easy to install apps via the command line
[5-7] : Now using choco it easy to install git and the dotnetcore sdk if you don't already have it installed
[9] : Once dotnetcore is installed we install powershell core as a dotnet global tool
[11-14] : Several PowerShell install commands for some additional pre-reqs needed to customize the appearance of our new terminal

Launch Windows Terminal and run code $settings > this will bring up VS Code with the Windows Terminal profile.json in it, look for a section with commandline="Windows.Terminal.PowershellCore"
```
{
  "$schema": "https://aka.ms/terminal-profiles-schema",

  "defaultProfile": "{61c54bbd-c2c6-5271-96e7-009a87ff44bb}",

  "profiles":
  {
      "defaults":
      {
          "fontFace":"Delugia Nerd Font",
          "acrylicOpacity": 0.8,
          "useAcrylic": true,
          "startingDirectory": "C:\\_"
      },
      "list":
      [
          {
              "guid": "{61c54bbd-c2c6-5271-96e7-009a87ff44bb}",
              "name": "E13",
              "commandline": "pwsh.exe",
              "hidden": false,
              "cursorShape": "vintage",
              "cursorColor": "#00ffff",
              "icon": "C:\\_\\_terminal\\e13_white.png",
              "backgroundImage": "C:\\_\\_terminal\\e13_white.png",
              "backgroundImageOpacity": 0.3,
              "backgroundImageAlignment": "bottomRight",
              "backgroundImageStretchMode": "none"
          },
          ...
      ]
  },

  "schemes": [],

  "keybindings": [
      { "command": "copy", "keys": ["ctrl+c"] },
      { "command": "paste", "keys": ["ctrl+v"] }
  ]
}
```
So lots of code here but the properties themselves are fairly self explanatory, let's look at the important sections:
- [4] : Terminal supports multiple terminals in a tabbed interface, this is the id of the profile that you would like to be the default tab that opens initially
- [8-14] : If there are settings that you would like to apply to all profiles, as an example I wanted to use the same font across all of my terminal profiles and always start in the C:_ directory where I have all of my cloned git repos
- [18-28] : For my default profile I have customized a pwsh terminal with a fun background image and colors, cursors, etc.
- [30] : You can have as many profiles as you want, on top of that Terminal will auto-detect many terminals that you may have installed such as WSL terminals
- [37-38] : In addition the visual modifications you can also define keybindings, by default ctrl+c/v (copy/paste) that I'm used to are not setup in order to avoid conflicts with people coming from Mac/Linux environments where those keys have other default meaning. But I've been a windows guy for so long that muscle memory is near impossible for me to retrain so I'll keep my old habits.
Open Windows Terminal again now that powershellcore is the default terminal and run "code $profile" > this will bring up VS Code to modify the behavior of pwsh
```
$global:DefaultUser = [System.Environment]::UserName

Import-Module posh-git
Import-Module oh-my-posh
Set-Theme Paradox
```
- [1] : This will make it so the default username@computername does not show up in the powerline. For my local development needs I don't need that
- [3-5] : Import the modules that we installed back in step 2 along with setting a theme that will enable powerline
Install a Font w/ Powerline Glyphs There are several different options, two that I have used:
- Cascadia Code PL
- Delugia Code
These aren't the only options and if you want an overload of options check out Nerd Fonts, the options are nearly limitless

We've done a lot, at this point your terminal should look something like the screenshot below. You'll see that this example the yellow powerline shows that this directory is a cloned git repo that has changes to be sync'd. In a following post I'll go through doing the same for a WSL profile.

So what do you think of Windows Terminal? did you configure powerline? How did you personalize your powershell core terminal? Please share in the comments below.

Special thanks to Christian Wiediger for the photo used in this post!