JAM Stack

Developer Experience

Developer Relations

Sitecore CDP/Personalize

Well, I have wrapped up from Sitecore Symposium last week.  Not fully recovered, but I wanted to blog about the topic for my session at Sitecore Symposium 2022 in Chicago.  Now the topic that I did, was on Developing for the Engagement Cloud, but one of the topics I covered that I want to talk about/recap here today, is the PoC (Proof of Concept) that I had built for this presentation for CDP/Personalize.  This PoC was meant to show a new and I will admit better way of building things in your tenant, using the tool that every developer is familiar with, which is Source Control.

## Where Did This Idea Come From

So a couple of months ago, I was told about some APIs that could be used for migration.  Now after exploring these APIs I realized they only covered a few specific use cases and that there was a greater need.  At the time, I knew that customers were delivered a UAT and a Production tenant, but everything was manual to move items between those environments.  However, the APIs that had been delivered was only for Decision Models, and not for what I considered developer tasks (I think this is a larger discussion for another blog post in the future).  So I started to dig in and research if there were any more APIs that could be used to solve my challenges.  This is when I stumbled upon a set of APIs that are being used by the frontend application of the tenant, but these same APIs are not currently documented anywhere.  These APIs are very powerful, and open up the door for a bunch of different use cases:

- Using Source Control
- Migration
- One-Off Accelerator Deployments

## What are these APIs?

As I just mentioned they are not currently in the official Sitecore documentation.  I’ve worked to try to determine why that is, and it’s simply because the APIs aren’t officially supported by Sitecore currently.  But does that mean you should avoid them? I don’t think that’s the case, and in fact, they open up and allow for automation scenarios that are too great to ignore.  So how do you find out about these APIs?  Well, it’s quite simple, if you log in to a CDP/Personalize tenant, open up `Chrome Tools` and view the network tab, you’ll notice as you interact with the interface, there are a lot of interactions taking place asynchronously, including with all of the APIs that I’m describing today.  Now I’ve spent some time documenting what I’ve found here and created a very rough draft Swagger document of these APIs: [https://dylanyoung-dev.github.io/sitecore-cdp-personalize-api-spec/](https://dylanyoung-dev.github.io/sitecore-cdp-personalize-api-spec/).  Just keep in mind that these are unofficial and something that I’ve personally spent time creating.  These undocumented APIs are listed under `Tenant Management`, this isn’t an official name for these, but these are the ones that are taking place in the browser.

## How to Start Using these APIs?

Okay, so now you know about the `hidden` APIs, but what do you do with them and how do you start using them?  Well, the first major hurdle you’ll deal with when using these APIs is authentication.  It’s different from the Batch, Stream, and Interactive APIs that you would typically use to ingest data to CDP/Personalize.  These APIs use OAuth to handle authentication, and there are two core ways to authenticate and get back the access token that you’ll use as a bearer token in the rest of the API requests.  There is the `password` grant type, which is where you would use your username and password for the tenant, to authenticate to use these APIs.  The problem with this approach is that if you have Multi-Factor Authentication (MFA) enabled, which is likely the case in a production environment, then you’ll need to pass in your MFA code as well.  This presents issues when you are trying to have a system run an automated process, such is the case during CI/CD DevOps deployments.  The second method is the preferred method of using `client credentials` grant type, which will use the `Client Key` and `API Token` from the API access panel in your tenant:

![](https://s3.us-west-2.amazonaws.com/secure.notion-static.com/2654d617-7be6-4274-86d0-7d1d7deee1e3/API-Access-panel.jpg?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Content-Sha256=UNSIGNED-PAYLOAD&X-Amz-Credential=AKIAT73L2G45EIPT3X45%2F20221028%2Fus-west-2%2Fs3%2Faws4_request&X-Amz-Date=20221028T174406Z&X-Amz-Expires=3600&X-Amz-Signature=615258348bbed9cbb22f0ee8aeec7c0b6a32e798ec47e5b177155af88a07ef8f&X-Amz-SignedHeaders=host&x-id=GetObject)

## Proof of Concept

So let’s talk a little more about the Proof of Concept (PoC) that I worked on that utilizes the APIs above.  I had this crazy idea in my head, maybe 6 months ago, that source control could be used instead to create and control the flow of various assets to a specific tenant.  Something like the diagram below was what I was envisioning.  At the same time that I was dreaming up this new approach, the product team was talking about how it would be nice to test these further, but in my mind, how do you just test a tenant’s assets directly?  I didn’t think the use case of randomly testing what was there, really made sense, and I thought it would make much more sense in a DevOps flow, where before you deploy to a tenant, you run unit tests and confirm they pass before you deploy, and then Automation tests could be done post-deploy to confirm if the changes were deployed successfully.

![](https://github.com/dylanyoung-dev/cdp-personalize-examples/raw/main/docs/images/Using-Source-Control.jpg)

Now as of this writing, I have only some simple examples of Unit Testing, and no examples of how to handle automation testing, but rest assured, that is the next part of what I’ll be working on next.  I now have two repositories that I’ll describe and link to below, but the serializer application needs to be broken apart into the SDK parts for calling the APIs, and then I should be able to share the Automated Testing scenarios utilizing that SDK.  So more on that to come.

But before I get into the projects, just wanted to describe the illustration above.  Simply put, a developer will no longer develop their changes directly in the tenant and instead will set up a repository with the serialized assets that they would build locally, and then there would be a process to deploy those changes to their tenant.  That’s where we would get into the repositories and their use cases.  Today all the examples use GitHub and Mocha for Unit testing, but my intention is for this PoC to be tech agnostic, so if you wanted to deploy changes, you could use Azure DevOps or GitLab, or any other Source Control Management system.  I plan to create a lot more content coming up on different scenarios that could be done for this PoC.  But with my PoC it is meant to be a community project, and thus all the repositories below are open source and I suspect will get way more traction as the community builds them out and other scenarios that these APIs can handle.

## Serializer Repository

This is the brains of the operation and where all the magic happens.  It takes everything that is in physical form (in a source control repository) and moves that (via a `deploy` command) using a Node CLI and moves that to a CDP/Personalize tenant.  Currently, the PoC that was originally created only includes examples for Decision, Audience, and Web Experience templates, but the plan is that it really should support anything that you would create in your tenant directly.  I always like to build things like this, to be unopinionated as possible, so those teams that have specific use cases should be able to handle their specific use cases using the same project.  So for example, if your organization is structured in a way where everything is done by developers and directed by a marketing team then your developers can configure as much as they desire in Source Control and have those assets deployed to their tenants.  Another use case, which I would assume is likely more common is that only certain assets are considered `developer` assets, such as templates, and then only those assets are in source control, while everything else falls outside of that and can be freely created in Source Control.

GitHub Repository: [https://github.com/dylanyoung-dev/sitecore-cdp-serializer](https://github.com/dylanyoung-dev/sitecore-cdp-serializer)

Available on NPM: [https://www.npmjs.com/package/sitecore-cdp-serializer](https://www.npmjs.com/package/sitecore-cdp-serializer)

## Examples Repository

This is the repository that shows how all this comes together to achieve the diagram above.  Now it’s opinionated because it uses a specific set of technology, such as Mocha and Super test for Unit/Automated tests and it also uses VS Code and GitHub Workflow for CI/CD deployments.  But it’s really easy to either create a template from this project and start creating it based on your own scenarios, or it’s also configured as a `template` repository, so when you land on the link below, you can click on `Use template` and you can start building based on this repository for your scenarios today. 

GitHub Repository: [https://github.com/dylanyoung-dev/cdp-personalize-examples](https://github.com/dylanyoung-dev/cdp-personalize-examples)

## Extra Credit

So all of this is great for customers but this opens up a new world for the community or partners that want to build out starter kits or accelerators for a specific industry.  For example, partner A builds experiences all the time for specific verticals like energy or health care, and could now use this strategy to either build a bunch of items for a specific industry so that those customers can get off the line faster.  Now I don’t have any specific examples of this today, but I challenge the community to contribute to these projects and start to create out these use cases.

Introducing Sitecore CDP/Personalize Serializer/CLI Tool

This week there was a question on the Sitecore slack, about how to recover a previously deleted experience/experiment.  It was pretty clear that the experience/experiment was still there, because when you tried to create a new experience/experiment with the exact same friendly id, it wouldn’t allow you to create the experience/experiment with that same friendlyId.  I had seen this before when working on my POC for Sitecore Symposium, that typically Sitecore Personalize will actually archive an item, instead of deleting it.  From my understanding, this is done to preserve analytical data that may have been collected about that experience/experiment.  However the UI doesn’t give the user any way to recover an archived experience/experiment.  It’s also, nice that it archives the item, instead of deleting it, because it makes it easy to recover the item at any point.  But in the UI it can be frustrating, if you wanted to use the specific name for an experiment/experience.

## APIs to the Rescue

Luckily during the work on the POC, that I’ll be introducing at Sitecore Symposium and on this blog in a few weeks as well, I discovered a bunch of kind of like management APIs for the tenants assets, which will come to the rescue in this case.  Now as of today these are not currently documented anywhere, except for possibly these [connection APIs](https://doc.sitecore.com/cdp/en/developers/sitecore-customer-data-platform--data-model-2-1/sitecore-cdp-connection-functions-rest-api.html), but unfortunately they don’t fully explain authentication, because authentication is different when working with this new set of APIs.  It uses oAuth to authenticate against `/v2/oauth/token`.  There is really two primary ways (grant types) for authentication to this API, but the result is the same, to get back a JWT access token that you would then use with additional endpoints.  To start authentication, I’ve provided a [Gist of a Postman collection](https://gist.github.com/dylanyoung-dev/8aa265cdc5c2d51810663886db3fd112) with the three authentication endpoints that I’ll detail below.

### Password Grant Type

The password grant type method, allows you to use your own CDP/Personalize username and password to authenticate to the tenant.  You will get back an access token and a refresh token.  The refresh token can be used with the Refresh Token endpoint that I also provided in the postman collection.

There is one challenge with this type of grant type, and that is MFA (multi-factor authentication).  If your tenant is a production tenant, it will likely require MFA, and in that case, you’ll have to pass the `code` parameter, with the value from your MFA device, in addition to the username/password combination.  That may not seem like a challenge, but it would be, if you are hoping to use this login to automate functionality, which was the case in my Sitecore Symposium presentation and POC.  

### Client Credentials Type

The second type of authentication is using client credentials which is very similar to the REST APIs used for ingestion, except you would pass these to the same `/v2/oauth/token` endpoint to get back a JWT access token.  Now that is all you will get back, there is no refresh token when using this method.  But the great thing about this grant type is that even if your tenant requires MFA, it does not require it with this grant type.  So if you want to achieve automation in some form, this is the grant type in a lot of cases that you’ll be looking for.

There are some issues, which are getting fixed, with this grant type.  The biggest is that this grant type doesn’t always work for all of the endpoints I’m about to talk about, including today’s Experiences and Experiment (Flow) endpoints.  But there are plans to add support for this grant type in the future for those APIs that throw errors when using this grant type.

## Using the APIs to View Our Deleted Experience/Experiment

Now that we’ve explained how you can authenticate, now we need to start querying data to see what information we have access to.  We’ll focus more on the topics of today’s blog, since there are many other APIs that can be used to achieve very many things.  I’ve created the following [Postman collection for these Flow APIs](https://gist.github.com/dylanyoung-dev/107afa7582739b291847191359937f19), that we’ll use in the next few paragraphs.  Before we get to far, at a minimum you will need to know either the `friendlyId` for the item you deleted, or its unique GUID.  I find it’s quite useful in most situations, to use the `friendlyId` since that uniquely identifies our items.

The first thing you’ll want to do is run a `GET` to Retrieve Flow Definition, which is at `/v3/flowDefinitions/:flowDefinitionId`, as previously mentioned, the flowDefinitionId can be its GUID or a `friendlyId`.  When you get the result set back, you should notice that you are being returned your deleted item, and that it’s set to archive: 

![](https://cdn.sanity.io/images/lanua4su/production/a7d389b354fbe787614cfcc02efd8fcdbfb3c7fb-1286x1031.jpg)

All we need to do, is use the `PUT` request (Update Flow Definition) that I provided in the Postman collection, by providing the `flowDefinitionId` which is like before, either the GUID or the `friendlyId` for the flow (Experience/Experiment) in Sitecore Personalize.  And then in the body, we’ll copy the contents of our `GET` request earlier, and inject those into the `BODY` as JSON.  Then update archive equals true, to now false.  Then run the request, and upon success, refresh your browser, you should now see the item in the UI.  Because the item was archived the name of the flow is now showing the previous name plus archived with a time stamp.  So if you are planning to use this existing flow, then you’ll need to ensure that you remove that name and update the flow to match your use cases.

## Additional Consideration

It’s important to note that this is a way around accidently deleting a flow (experience/experiment), but there may be other risk factors that aren’t entirely clear at this point.  You should do thorough testing to ensure that your experiment or experiences are working as expected after an item was archived.

Also these APIs described above are not in Sitecore documentation.  There is work to get them added, and once documentation is available I’ll include links to the documentation.  Also I've created an unofficial [Sitecore CDP/Personalize API Swagger reference](https://dylanyoung-dev.github.io/sitecore-cdp-personalize-api-spec/) that you can view on GitHub, that I'll likely use in future blog content.

Sitecore Personalize: How to Recover an Archived/Deleted Experience or Experiment

Some of you may know that this site is hosted on Netlify.  But recently I was experiencing weird issues with different environments and the source not always building consistently across multiple machines.  Obviously the build system that runs when Netlify detects a change to the source code or a triggered build is fired when I’ve created a new article, would be another system that needs to build the repository.  After a lot of digging, I started to realize that this solution only optimally runs on a very specific version of Node and NPM.  

## Specifying Engine Details in NPM

So I needed a way to instruct those that are trying to build my repository for this site, to tell it specifically what version of npm/node to use.  I found that this is quite easy to do, but requires some configuration in your `package.json`:


```json
{
  "engines": {
    "node": ">=0.10.3 <15",
    "npm": ">=1.0.20"
  }
}
```

For more information about this, you can refer to the [documentation available from NPM](https://docs.npmjs.com/cli/v8/configuring-npm/package-json#engines).

Once you’ve configured the engines in your package.json, you’ll also want to look at creating a `.npmrc` file to control when this engine definition is enforced (otherwise its just optional and will display a friendlier warning in the console when you try to do a build, vs blocking the build if it’s set to strict).  

```json
engine-strict=true
```

## What about ensuring Netlify builds with the correct version?

So the details that we specified above are great, especially if we want to ensure every developer working on our project is using the same requirements to run and work on the solution.  In fact, I would say that if you are starting a new project, you will almost certainly want to provide this detail to ensure everyone is using the correct version.  But even after making those changes above, I found that the Netlify builds were still using the default `12.x` node version to do my builds for my project.  So what am I missing?

Well, it turns out I needed, at least for Netlify, to create a new file `.nvmrc`.  Now NVM (Node Version Manager), if you’ve never used this before, this is also an almost necessity if you are developing with node locally because each project that you are building locally could easily require a different node or npm version.  NVM solves all of those issues by managing multiple versions of Node on your machine.  If you need to switch to a different node version, you can simply either install that version using `nvm install 12.x.x` or whatever the version may be, but also you can use the `nvm list` command to see a list of all the installed versions of npm/node that NVM is managing for you. 

But either way, it appears that the Netlify build is using NVM as well to manage which version of node/npm to run.  So now it’s actually quite easy to just specify the version we need in our `.nvmrc` file:

```json
v14.16.1
```

Once I committed that change, I was now seeing that the Netlify builds were downloading if the build agent hadn’t already installed that version, and if it had, it would go ahead and use the version that I specified.  Pretty neat stuff, so at the end of this, I can now ensure that local development is using the correct versions of npm/node, as well as the Netlify build servers.  Now I can take on a feature task in my repository to ensure it works with the latest lts of node/npm and then update everything to match that version.

## Extra Credit

So I was thinking about how this behavior of using `nvm use` works for our Netlify builds but for some reason it doesn’t seem to be working for `nvm-windows`.  After some quick googling, I came [across this post](https://gist.github.com/danpetitt/e87dabb707079e1bfaf797d0f5f798f2), provides an alias work around which gives the same outcome, since this functionality of the `nvm use` command, picking up the current `.nvmrc` file is only supported in Linux.  So definitely something worth adding, so the next time you work on a node/npm project, you can just run your simple alias command, and start using the specific versions of both engines immediately.  Pretty cool!

How to Change the Node Version for Netlify Builds

As the excerpt described, I have been working on a video for the Discover Sitecore YouTube channel related to Sitecore CDP/Personalize with the use of Real-time, also referred to as the Stream APIs typically used by the Sitecore CDP JavaScript library to track events in the browser.  Technically by using the API’s I am in essence mimicking the behavior you might trigger if another system wanted to track behavior such as a Mobile application or maybe even a third-party system.

As was the case with Sitecore XP, it was always great if you could kill the .NET session, especially when you wanted to test the output of something you might be demonstrating to a customer in real-time or content for a video/blog.  Unlike in the days of the .NET development and the .NET application with XP, where you might need to build a custom admin page that you could call while logged in to kill the session, in the realm of Sitecore CDP, you have a way to do this at any point, as long as you have a Browser Ref.  In a previous blog topic on my blog about [Getting the Guest Ref from the Browser Ref](https://dylanyoung.dev/insights/getting-the-guestref-in-the-browser-with-sitecore-cdp-personalize/), I talked a little more about these different references.  So you could theoretically kill the session at any point for the user by writing some JavaScript, but I’ll cover today how to do this using an API request using Postman.  You might be in the middle of a demonstration like I was when creating the YouTube content, and need to show the browsed session versus the open session in Sitecore CDP (keeping in mind that CDP is the only way to view your guest data).

I’m going to show this in postman, but anything could work here to make these requests including CURL.

You can view the postman request script here if you would like to import this into Postman: [Gist Postman Script](https://gist.github.com/dylanyoung-dev/021d15d6662bca74635624c474a72866).

Or you can just refer to the screenshots below.  You’ll need to create an environment for your specific Tenant of CDP/Personalize and then you’ll need values for the following:

- API Endpoint - This is for your region such as `api-us` if you are accessing a tenant in the US
- ClientKey - This is the public key for accessing your tenant.
- Message - This should be left blank and filled with your pre-request script details
- POS - This is the point of sale that you specified earlier when you set up your tenant and start ingesting data.
- Browser ID - This is a variable that you should’ve defined previously.  Such as when you created the session you would want to store this Browser Ref for future requests, however, if you just want to use an arbitrary value, that can be done as well.

![Includes Request Details to Close or Kill the Session in Postman for Sitecore CDP/Personalize](https://cdn.sanity.io/images/lanua4su/production/add1b2d9c611e2f511ee150b789fdef64bb00e99-950x570.jpg)

![Includes details for the creation of the {{message}} variable for the request in Sitecore CDP/Personalize.](https://cdn.sanity.io/images/lanua4su/production/495fa4382aa50c85a8ede42e2c49bb7734b60c82-950x570.jpg)

Closing a Session in Sitecore CDP with the Stream API Using Postman


I've been curious about this topic for quite some time.  As a Sitecore developer, I knew it was easy to build a .Net core CLI (Command Line Interface) application, and in fact, there is already one available from Sitecore that was extensible.  Technically I would say JSS falls into this category as well and is Node-based.  But before we get into this topic at a deeper level, I wanted to briefly talk about why I wanted to learn this and potentially build my own Node-based CLI.


So for Sitecore development in general, everything has always been done in .Net.  For a .Net developer wanting to run a CLI, it seemed only natural for them to either already have the .Net runtime to run the CLI or for them to download the required framework.  But I wondered is that feasible for a frontend developer?  Now sure to run a Node CLI, you have to have node, but I would argue that there are way more developers in general running Node today than running .Net runtime.  And especially if you are targeting the typical Frontend developer, they might not even know much about .Net at all.  So it just seemed like a good idea to build a CLI, potentially for Sitecore (but I might take it further in the future) using Node so that more Frontend developers don't have to jump through the .Net hoops.  Frontend developers used to the Javascript Frameworks of today, can stick to the tools they are used to, while .Net developers could theoretically continue to use the .Net CLI.

So that is the premise behind this curiosity, but I wasn't sure it was feasible yet, and probably still won't know in the immediate term how feasible it really is, but I figured I'd write about my journey nonetheless.

## Running a CLI with Node

So before I start building a CLI, I wanted to talk a little bit about the nuances of running a CLI.  If you are a .Net developer, or not that familiar with NPM, this section is for you.  Now first off it's important to know the differences between Node and NPM.  Node is simply the runtime, allowing you to write Javascript and have that run on your machine (similar to how the .Net runtime works for .Net), while NPM is nothing more than a place to store your node scripts and allow users to consume them (similar to Nuget).  We are going to use NPM to distribute and run our Node CLI, which we’ll cover how to take our simple CLI and use Github Actions to deploy that out to NPM.  There are a couple of ways a user can run a CLI with NPM.  They could install an NPM package globally and run it with a simple npm command:

```javascript
> npm i speed-test -g

> speed-test
```

Now that it's been installed locally you can simply just run `speed-test` in your command line to run a speed test (this is just an example of a CLI you can use).  This method of running a CLI is great if you need to run this CLI often.  An example of a CLI you may run multiple times could be `yo` which runs Yeoman which is a Node/Javascript-based templating engine.  But what if you just want to run something once?  Well as of version 5.2.0+ of npm, it now includes something called `npx`, which just gives you the ability to run any npm package one time.  This is quite useful for running CLI commands.  An example of this is when you want to create a `React` project, you might run the following command:

```javascript
> npx create-react-app my-react-project
```

So this npx command will execute the npm package called `create-react-app` which will be useful for generating the needed starter kit template to run React.

## Building our Node CLI application

So now that you know how you can run a CLI application based on Node, let's explore how you would create your first node CLI application.  It’s quite easy to get started, you’ll likely need a GitHub repository (especially if you want to use Github actions to deploy to npm covered in a future article), or if not, you’ll need a folder for where your application will begin to be built.  If using a repository, clone this repository locally, this is where I’ll begin this topic.  If you are not sure how to clone a repository, definitely check out this topic where I covered how to use the CLI to run common git actions.  If you want to skip ahead, you can navigate directly to the repository here.

So once we have a blank repository, we need to start by initializing Node by running the following command:

```javascript
> npm init -y
```

And then that will create a package.json file with all the default options.  If you would like to choose options as you go, just leave off the `-y` flag, and then you’ll be required to answer the questions, or just press enter to go with the default options.

We next should install some common CLI packages that might be useful in our CLI application.  Obviously, not all of these are required, but most with be helpful.

- Commander: This package will make it easier with several helpful options for commands, options, etc.
- Chalk: This allows us to output colored messages.

To install these, just run the following command:

```javascript
> npm i commander chalk
```

Once those are installed, I’ll go ahead and create a `src` folder that will contain our code for the CLI application.  I also plan to use typescript for this application, so to initialize typescript, in the root, also run the following commands to get setup:

```javascript
> npm i typescript@latest @types/node

> npx tsc --init
```

These steps will create a tsconfig.json in your root directory and tells typescript how to compile the typescript and output javascript.  Now let's jump into some of the changes you’ll need to make to your `package.json` file.  At any point, you can refer to this [repository on GitHub](https://github.com/dylanyoung-dev/first-node-cli) to see the final product.

```javascript
{
  "name": "first-node-cli",
  "version": "1.0.0",
  "description": "Just a play repo that I'll use in my blog series",
  "main": "index.js",
  "scripts": {
    "build": "tsc",
    "start": "ts-node ./src/bin/index.ts",
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "repository": {
    "type": "git",
    "url": "git+https://github.com/dylanyoung-dev/first-node-cli.git"
  },
  "bin": {
    "test-cli": "./src/bin/index.ts"
  },
  "author": "",
  "license": "ISC",
  "bugs": {
    "url": "https://github.com/dylanyoung-dev/first-node-cli/issues"
  },
  "homepage": "https://github.com/dylanyoung-dev/first-node-cli#readme",
  "dependencies": {
    "@types/node": "^18.6.1",
    "chalk": "4.1.2",
    "commander": "^9.4.0",
    "typescript": "^4.7.4"
  }
}
```

You’ll need to add two `scripts` that are missing, one for the Typescript build `"build": "tsc"` and then another one for start `"start": "ts-node ./src/bin/index.ts"` these we’ll use later.  Then you’ll also need to create a bin definition:

```javascript
"bin": {
	"test-cli": "./src/bin/index.ts"
}
```

This is so that when we type in a command into the command line, it’ll know what phrase to use to trigger the command `test-cli` and then what file to run.

Now that’s it for the package.json, now let's create two files.  One called index.ts (`/src/bin/index.ts`) with the contents below.   This is the primary starting point for the application, where you can place other imports if you were building more than a simple “Hello World” repository.  

```javascript
#!/usr/bin/env node
import { Command } from 'commander';
import * as packageJson from '../../package.json';
import { sayHello } from '../test';

const program = new Command();

program.version(packageJson.version)
    .command('say-hello')
    .description('A simple CLI tool to say hello')
    .action(() => {
        sayHello();
    }
    )
    .parse(process.argv);
```

This code really shows how the `commander` npm package really helps with the Node CLI, because you can specify a command, in this case, `test-cli say-hello` would be used to now run the action `sayHello();`. You can also provide options or arguments here as well if your CLI needs user-provided data.

You’ll also need to create an `/src/test.ts` file, which will contain our sayHello function which our commander function calls into.  At this point, we just output our Hello World, using the npm package for chalk which allows us to use different colors in our command line.

```javascript
import chalk from 'chalk';

const sayHello = () => {
  console.log(chalk.green('Hello World!'));
}
```

## Testing Your CLI

Once you’ve completed writing your application, there are a couple of different wants to test it out, but I found the following one of the better ways, plus if you are creating some form of CLI that works with a separate folder on your machine, I found this is the closest to the experience you would have if you pulled the package from NPM directly.

You’ll first need to build your NPM package, and in a previous step, we created an NPM script called `build` which we can use to facilitate the Typescript build process.  We can run the following command below to run the build script.

```bash
> npm run build
```

Then once it’s built, you can then run an NPM link command, which basically links the global npm command for this NPM package to this local folder, so that we can run the `test-cli` anywhere, and in any folder.

```bash
> npm link
```

So once you’ve run that command, you should now be able to run the following command anywhere else globally that you would like, and your output should be a green `Hello World` message.

```bash
> test-cli say-hello 
```

Well that completes today’s content.  I will continue this post in my next article, where I will cover how to create a basic CI/CD process using Github Actions to publish our CLI out to NPM.  This will then allow us to run npx test-cli or to install it globally or locally for various needs in a specific application.

Building Your First Node JS CLI

Yesterday I got the notification I had been waiting for.  I had seen some demo's of Github Copilot and I was eager to play around with it.  Before I talk about it and show some of what it's good at (vs what it's not good at), I wanted to calm the fears of those of you that are reading this and thinking oh no, this will replace my job.  Maybe one day that will be the case, but this will be nothing more than a more sophisticated intellisense and not something that will replace your job, atleast in the next 10 to 20 years, so stop worrying.  Maybe one day robotics/AI will replace all work, and our machine overlords will just pamper us while we sit and do nothing.  But for now and in the immediate future, you can be assured that if AI starts replacing technical roles (which actually sounds scary that machines will start coding themselves, sounds like the beginning of the end), that there will be many other jobs replaced by that time, and mankind will likely need to grapple with if it's worth it before it gets to that point.

## First thoughts - More than advanced intellisense

So if you get past those initial fears, lets look at Copilot and what can it really do?  I've had it for less than 24 hours now, and I think where it's really going to be great help, is assisting the developer.  I think it'll be great at replacing Stackoverflow usage.  If you are not sure how to write a switch statement in typescript or python, you can use it to assist in writing the code you need.  It's more than just intellisense!  When I first saw it in a video broadcast by [Jack Herrington](https://www.jackherrington.com/), I thought, well this will just be a smarter intellisense, but its more than that, because it can write full functions for you.  But that's where it ends, you have to know what you are trying to write, to get the best results out of it.  There's always so much complexity in writing an application, that I don't see this getting to that point anytime soon.  Here is an example below.  I tried to have it create another fetch function in my personal blog code, it did pretty well, it knew it needed to extend the array returned to more than just one item.  I'm assuming it reviewed the logic above and altered it, which is pretty impressive to say the least.  It knew because I gave it the subtle naming hint with a constant that was plural vs singular, that I wanted similar code, but one with more items returned.  Sounds awesome, but weirdly some times it just throws out garbage results as well.  I think it'll take some more learning to improve, but here is the example:

![Github Copilot Basic Example](https://cdn.sanity.io/images/lanua4su/production/ef59a89b39ba3379d1c23ca9e6b3d05a32626338-800x450.gif)

That's a very basic example in that demonstration, but it can do more than just that.  You can write comment instructions, and it'll use that information to create the function (or atleast attempt to write it for you). 
 I also like that this encourages you to write comments. So for example, if you weren't sure how to write a switch statement or a React Functional Component, it will help you write that.  Really just replacing the benefits of Stackoverflow.

Here in this next example, I ask it via a comment to create a function that adds two numbers together.  The default suggestion actually wasn't what I was looking for, it was correct but in comment form.  I could've easily accepted that but had to erase the comment for that line, but there's actually a way to see more suggestions (it'll show you what it thinks is the best suggestion, but it may not always be what you want).  At any point you can pretty `Ctrl + Enter` and it'll pop open a new window with all of the options where then you can "Accept" a solution.

![Github Copilot Advanced Example](https://cdn.sanity.io/images/lanua4su/production/47b1d48eb0a12d0209ac02ffc7284c6594e35bc5-1200x676.gif)

I just wonder about two things with these capabilities.  First off will the suggestions improve over time (I'll do a follow up post in about a month with updated thoughts).  And will those improvements occur for me only or for everyone.  I think different developers have different preferences, styles, etc. and I would like to see an element to this that allows it to adapt to my style over time.  The other concern I have, will the suggestions it provides, will they always be the best way to implement something?  I think that determination is still something that's left to the developer.  That's where AI can't help here, and real intelligence to make that determination is needed.  I don't think copilot will ever write an entire application, but I think it'll be a vital tool in the toolbox of a developer, similar to how stackoverflow and intellisense are vital tools for the developer today.

Also I only played around with Typescript and Javascript, there is an extension also for Visual Studio that I'll install before my next writing, and it should also be good at assisting with C# code as well.  I've never coded Python before, and I think this is where Github Copilot will provide the best assistance, working with syntax I'm not familiar with, I can use Copilot to help me learn Python faster.  Basically, if I'm unaware of the correct syntax of the language, I can essentially ask it via comments, `Create a Switch statement between 5 options` or something like that, and it should output Python (or other languages that it currently supports) that can really help me learn the syntax faster, because I can now get help from within the IDE.  Makes you wonder why they never added code searching from within the IDE, not to find stuff in your code, but to find snippets quickly.  That's what Github Copilot reminds me of the most.

## Conclusion

So to follow up, does this new tool replace developers? No, in fact I think it'll speed up efficiency and potentially quality. Also will help developers with new language learning. I don't think you'll need to google as much stuff, because that's essentially what it's doing for you, you instruct it with what you want to write, just like you would in a google search query, and it'll return the best guess, using Open AI technology to do so.  The product is currently in Tech Preview, if you would like to play with it as well, check out [Github Copilot](https://copilot.github.com/) and signup.  I received my invite to the program via e-mail in a week or two, so you shouldn't have to wait long.

First Look at Github CoPilot - AI Powered Programming

A quick little post as I'm playing around with Sitecore CDP/Personalize.  I've been playing around with the API's to get guest data.  But I found that if I run this command in the developer console:

```
Boxever.getID()
```

This returned ID, is not the same thing as the Guest Ref, it's actually the Browser Id, and typically associated with the Cookie.  You can use this ID inside your CDP/Personalize tenant and get the Guest Ref, but I've always found this a little confusing.  It's funny how it all makes a little more sense now.  When you search in the CDP/Personalize tenant with the Boxever Browser ID, it'll show a different ID in the Guest Profile, than you would expect to see.  I just wrote this off and thought it could be a bug.  But actually, this ID is the Guest Ref:

![Boxever.getID() vs guestRef](https://cdn.sanity.io/images/lanua4su/production/9eb08025c17dafead05f3909f717a82dc2a45a4a-1232x647.jpg)

Now that I finally know that these are two different things, what if I wanted to get the guestRef from the browser.  There is a way, and I found this from [Sarah O'Reilly](https://sitecore.stackexchange.com/a/30991/1000):

```
Boxever.browserShow(Boxever.browser_id, Boxever.client_key, function(data) 
{ 
  console.log(data)
}, 'json');
```

Why do you need the guestRef? Well if you plan to do anything with the APIs, you'll need to know the guestRef in order to interact with them.

Getting the GuestRef in the Browser with Sitecore CDP/Personalize

So I'll admit it, I've never been much of a CLI or terminal guy, however times are changing.  As I've started to use JavaScript frameworks more frequently, it seems only natural to start using the terminal more frequently.  Now I want to do all things in the terminal, but one last hold out I've had was using Git in the terminal.  As a prior GUI interface user, it was always just easier to use VSCode or Visual Studio to do all the underlying commands for me and just push buttons instead.  But like I said, times are changing and I wanted to become more of a power user via the CLI.  As I've learned new things, I wanted to take you along for that journey.

## Getting Started

So technically I am using Github for a large portion of my Git development these days, and technically there is a [CLI for Github](https://cli.github.com/) specifically, but for this, I'm going to stick to git commands directly.  If you haven't configured Git for your local development machine, [follow this guide](https://www.youtube.com/watch?v=4xqVv2lTo40).

So I'm going to walk through the generalized steps to getting started with git, as if you are using Github for an open source project.  So the first most basic step to getting working with a repository, is to clone that repository locally:

More Information (+ Definition): [Learn More Here](https://docs.github.com/en/repositories/creating-and-managing-repositories/cloning-a-repository#about-cloning-a-repository)

```
  git clone https://github.com/username/some-repo.git
```

If you want, you can optionally append a path to the above command, to specify where the system will clone the files.  You can also specify just `.` to have it clone into your current folder.  So for example:

```
  git clone https://github.com/username/some-repo.git .
```

## Getting Your Code Added

So cloning is the most basic step to getting started with Source control, and honestly this was one command I've always used the CLI to accomplish, because it's just easier.  The alternatives were always way more complicated.  But now lets explore the world of committing changes to Source control.

So once you've cloned, this is usually where you'll start making your changes.  Obviously if you've cloned an existing repository or a Template repository, you'll already have files in your repo, but for this exercise, we'll explore the initial steps to add files to be tracked by `Git`.

With a blank repository, it's time to start adding files.  This could mean adding a Next Js app to your repository or just a simple Html file.  Here I'll leave this a little up to you on how you choose to go.  Now that you've got some files, it's important to understand the types of files that you might have.  With any source control project, there is likely to be files that you want to share with the team, and local files that either has specific environment variables for your local environment, or build files etc.  Committing those to source control will create issues, because every time anyone on the team needs to commit changes, they will commit their local environment changes or build configuration, leading to either unnecessary changes being in Source Control, or even worse than that, everyone's local environment breaking everytime they get latest changes from the rest of the team.

This we do not want, so lets explore the file that can help you get around these changes.  The `.gitignore` file will allow us to commit a file that instructs git not to commit specific paths.  Another useful file is the `.gitkeep` since you cannot commit empty folders into source control.  If you have folders that are used for build output etc., you'll want these folders present, but empty, so the `.gitkeep` is your path to keeping everything present for your team of developers.  

Once you've determined what you want to commit or what you don't, your first step is to instruct Git that you want these files added to source control.  They will not be tracked until they have been added to Git to be tracked. Now this is where the Gui changes, it technically combines this step into one step (Add + Committing), so if you are used to the GUI, you will likely make changes and see even new files, ready to be committed, this is because it will handle both steps as one.  But with the CLI, this flow is now a little different. (Although part two when we discuss Aliases, could be a better option to combine your commands) 

You can add all files or just one files.  Since we are just getting started, we'd like to just get everything added.

> But Wait! How do you know if all your git ignore configurations are set correctly.  Sure you can always add and then remove, but that just adds extra work, and no one likes that.  You can actually do a dry run first, just to see what it would add if you did run the command for real:

```
  git add . --dry-run
```

So the above command will add all items, that's what the `.` represents, and then pass in the flag `--dry-run` just to see what your actions might do.  If you see errors, nows your chance to update the `.gitignore` to ignore the correct files.  But if you've run the dry run and everything looks good, now lets run the command for real:

```
git add .
```

So now you've added your changes, which basically means that they can now be tracked by source control, but you have not committed or pushed those changes to the remote repository yet.  Another useful command is this:

```
git status
```

This command will give you a status of your situation.  In my case, it tells me the branch that I'm working on (I'll cover branching in part two of this series), what commits I've made, and finally the changes waiting to be committed (and sitting in staging).

> What is "Staging" you might be asking.  Well there is an official definition, but really its just a queue where the files you want to commit to source control sit.  But there is two queue's, one where files have changes and are ready to commit, and then staged changes which will be committed with your next commit command.  So why is there a distinction there? Well sometimes you might not be ready to commit all of your changes, or you might want to committ your changes in multiple commits, either case, I have found this feature extremely helpful at times.

But once you are ready to commit your changes, its actually quite easy to do so, by using the following command:

```
  git commit -m "Commit Message"
```

I won't go into specifics of the art of naming your commit, but it should be descriptive of the changes that you are making.  Working on a specific Jira ticket, go ahead and mention it.  Make it clear so that any other devs working on this project later on, will understand what you changed and why.  Once you've run that command, your local file system should no longer show any pending changes.  But you aren't quite yet done.  There is one last task to be completed.  You need to push your changes up to the remote repository so that others can access your changes as well.

It's really actually quite easy to do that via the CLI as well.  Just run the following command:

```
  git push
```

With pretty much every CLI command that you might run, it's possible to add the flag `--dry-run` to just see what the command might do.  That way you can be sure what actions these commands will take.

That pretty much completes this guide.  These are the basic steps needed to clone, add and commit changes to source control, using the CLI.

Introduction to the Git CLI - Simple Commands

One of my weekend projects I've been working on for probably at least a month now, has been an `Express Js` Api for an idea I have for personal uses.  It's been a slow project, because I'm still learning the basics of `Node Js` as well as it's only something I spend time on when I feel like coding.  But all the same I'm still learning and trying to build something useful and as I learn, I'll share more and more of what I've been learning with this blog.

One of the challenges I face as I continue this journey is that I'm still learning the syntax.  With VSCode unlike Visual Studio, it's hard to know the right syntax to use for every use case.  There are traditional functions, and then arrow functions, and knowing why and when to use what is honestly the biggest challenge I've faced with learning modern JS framework patterns.  And then even when I know what I should use in a specific scenario, I find I forget the syntax to use, so today's topic has really helped improve my efficiency when writing my application.

## Snippets

Well as it turns out, you can actually use snippets in VSCode.  There is a way to install extensions that contain code snippets, these are quite useful as an example:

- https://marketplace.visualstudio.com/items?itemName=chris-noring.node-snippets
- https://marketplace.visualstudio.com/items?itemName=xabikos.ReactSnippets

But what if you didn't find these as useful and you wanted to create your own? Well it turns out that this is quite easy to do.  There are actually a couple of different options that you have if you want to create your own:

 - Project Snippets
 - Global/Language Snippets

I'm going to focus in this blog on the `Project` Snippets, because although it's great that you can create snippets for yourself, I don't think that's necessarily the best approach, because if you are working on an Express app, why not create project level snippets that everyone in the project can use, instead of just your snippets.  I think the easiest way to create Project Snippets is to follow the instructions below.

## Creating Project Scoped Snippets

If you don't already, create in the root of your project a `.vscode` folder, that will contain your snippets.  The files contained within this folder can be language specific or just general in nature, which you can specify by providing a scope attribute to the json file that you create.  So lets get started, inside your `.vscode` folder, create your first code snippet file.  I called mine `primary.code-snippet`.  This file will contain all of my snippets in one file.  An optional variation is to create multiple files with distinct contents in those files (ex. a file that has only react code snippets in it for example).

If the `.vscode` folder already existed, it may already contain a settings.json file, which is used to influence vscode settings for the project (shared with everyone, if committed to source control).  So we now have something like this:

![VS Code Folder Structure](https://cdn.sanity.io/images/lanua4su/production/fede15e777048891738bc1232fcee589c51b2ea2-362x110.jpg)

So lets take a look at our newly created file.  I've gone ahead and added an example you could use in your code snippets file.  I've included a snippet that you can use in a javascript file to output a GUID, when you type the prefix: `outputid`:

```
{
    "outputid": {
        "scope": "javascript",
        "prefix": "outputid",
        "body": "$UUID"
    }
}
```

So the .code-snippets file contains essentially an collection of json objects where you can specify your snippets.  The `prefix` is your trigger word, `scope` is how you scope this to only show up in javascript in this example, and then `body` is what will be output when you type your prefix into a javascript file.

It's a simplistic example, so below is a few other use cases.  Like I said above, you can also have multiple definitions in this file, as well as defining no scope and/or multiple scopes as demonstrated below:

```
{
  "Import external module.": {
    "prefix": "import statement",
    "description": "Import external module.",
    "body": ["import { $0 } from '${1:module}';"]
  },
  "React Functional Component": {
    "prefix": "reactfc",
    "scope": "javascriptreact,typescriptreact,javascript",
    "description": "Create a React Functional Component",
    "body": ["const Component: React.FC<> = () => {", "    ", "}", ""]
  },
  "README.md": {
    "prefix": "README",
    "description": "A README.md template",
    "body": [
      "# Project Name",
      "",
      "> Short description",
      "",
      "![Preview](images/preview.gif)",
      "",
      "Long description",
      "",
      "## Installation",
      "Installation instructions",
      "",
      "## Usage",
      "Usage instructions",
      "",
      "## Development",
      "Development instructions",
      "",
      "## Author",
      "Author name",
      "",
      "## License",
      "License name",
      "$0"
    ]
  }
}
```

Note that you can also have a description attribute as well, in case you would like to further explain your code snippet when someone is using it.

Also note that the prefix can include a space.  I don't particularly like this syntax, but it's an option.  Because this definition didn't include a scope, you can add an `import {} from 'module';` in practically any file that you work with, within VSCode.

When scoping refer to this list for a full set of scope language restrictions: https://code.visualstudio.com/docs/languages/identifiers#_known-language-identifiers

Or you can also define new language definitions, at the top of the link just provided.

Happy Coding Everyone!

Become a VSCode Power User while using Project Code Snippets

So in my journey with this new domain, one challenge that was presented to me, was the need to 301 my existing sitecoremaster.com domain to my new blog.  This used to be an easy proposition in the realm of .Net.  But lets explore my journey to the answer I finished with.

But like everything as I've transitioned from .Net to Next.js/React development, it requires a complete shift.  First I explored handling this in Next.js.  It's complicated because Next.js handles server side functionality as well as client side.  But in my case Next.js is only handling the Static Site Generation (SSG) for the Jamstack approach, running through Netlify.

## Next.js

So my first thought was that this is something that Next.js can handle, because I know it has the capabilities of handling Server side generation.  I also know there is features to handle 301's, but it turns out, this can only handle page 301 redirects, not necessary anything related to the tld redirect.

So for example in your `next.config.js` you could define something like this:

```
module.exports = {
  async redirects() {
    return [
       { source: '/about', destination: '/', permanent: true },
    ]
  },
}
```

And then essentially define in that array as many redirects as you want to handle.  You can even include path matching, in case you wanted to redirect where your blog articles sit on your website.  Quite powerful for custom scenarios, but for my scenario, this just didn't quite do the job, since I had a whole different domain redirecting into my current one.

Also most of my site is Statically generated using Next.js's Static Site Generation (SSG) functionality.  And this is even more of an issue when you introduce Netlify, which is really meant to handle SSG sites versus a node based environment.  In other words, you can't easily run server side applications on this platform (unless you use serverless functionality, but I don't want to get into that topic for today's video).

## Netlify

So after further research it dawned on me that I needed to essentially revert back to the old .Net/IIS days where I would handle this in a redirects config in the web.config.  Even though you are using files, what you are really doing is instructing IIS to handle the redirects and therefore you have more control.

So Netlify to the rescue, however some steps were needed to get to the final solution.  First off, I needed to point my old Sitecoremaster.com site to Netlify.  It's actually quite easy to setup custom domains in Netlify (https://docs.netlify.com/domains-https/custom-domains/).  I needed to point Sitecoremaster to the same site definition in Netlify.

![Netlify Domain Configuration](https://cdn.sanity.io/images/lanua4su/production/f26a5042290840ea49569787e9c142d450a4fe48-958x716.jpg)

As you can see, I have the domains attached.  Once any DNS information is tied up, you should start seeing that the new domain that you want to 301 is now pointing also to the new location.  So now, you just need to handle the 301.  After poking around the documentation, I discovered that most of this is or well could/should be handled by your netlify.toml file.  It was actually quite easy to setup, although I tried to find a way to do the canonical version with wildcards, which for some reason didn't want to work correctly.

This is essentially the changes that I made: (https://github.com/dylanyoung-dev/website/blob/main/netlify.toml#L6:L16)

```
[[redirects]]
from = "https://www.sitecoremaster.com/*"
to = "https://dylanyoung.dev/"
status = 301
force = true

[[redirects]]
from = "https://sitecoremaster.com/*"
to = "https://dylanyoung.dev/"
status = 301
force = true
```

Basically redirecting `www` or `non-www` urls all back to the same `https://dylanyoung.dev`.  

Configuration of 301 Redirects with Netlify and Next.Js

For those that are still getting used to my new blog, welcome! This site isn't just a new Wordpress theme on top of Wordpress.  I've been dying for years to play around with Next.js and modern JS Frameworks.  There are so many good reasons to take the journey (will be sharing videos/content on this journey coming up).  Most probably didn't know, that I used to host my blog on wordpress, but the signs showed me that it was time to go at it a different way.

## Sanity.io (CMS)
No blog is complete without a CMS to drive it.  I wanted something in this case that was Headless and flexible.  That will work well with Next.js as well.  What I liked about Sanity is that it's simplistic and easy to modify and add custom schemas for all types of data (since I plan to extend this site beyond blog content at some point in the future).  It also consists of an open source studio that can be extended and installed along side the application

## Next.Js (client)
So I went with a Next.js implementation for this site.  I am a long time .Net developer, having started with Classic ASP, then to VB.Net and finally to c# (following the frameworks along the way).  The source for the site is publicly available on my Github !(https://github.com/dylanyoung-dev/website) so definitely check it out.  I still need to write more documentation so others can work on it.  I have some really awesome content coming up with some topics that surround this and my blog. But in the meantime, just wanted to share some of the nuances of what I've configured.  

When you view the repository for the first time, you will see two distinct folders, one for the `studio` and the other for the `web` client.  The `studio` is the Sanity.io interface for editing content.  It lives on a sub domain url and deployed to differently in Netlify.  It's based on a React open source application.  When you initialize sanity, it'll pull in this source which you can later either modify or extend.  Their is the concept of `sanity plugins` that are nothing more than NPM packages that you can pull into your application (https://www.sanity.io/plugins).  So if you want a fancy media browser or other functionality that builds on top of Sanity initial installation, you can do that.  I love the way it's simplistic and extendable.  `Studio` exists in a mono repo along side the client (a React/Next.js application).

## Netlify

This is actually my second site I'm hosting with Netlify.  I like it because it's simple and easy to configure.  I considered going with the obvious choice of Vercel since I'm using Next.js.  I'll show more content soon on how Netlify is configured along side the repository and changes in Sanity for achieving a JAM stack approach.

## Jamstack Setup

This site also uses SSG capabilities of Next Js paired with Netlify to auto generate the html version of the site (with the blog content).  I still have a list of enhancements I'd like to make as I gain more experience.  Right now, all the content is generated each time I run the build, where as it would be great to achieve some incremental builds instead when I release new content.  But with the Jamstack approach, because of it's nature, I have very solid light house scores.  With still room for improvement, but better than any sites I used to create while working with .Net.

![Page Speed Lighthouse Scores](https://cdn.sanity.io/images/lanua4su/production/4368781b46ab1617017614870ed07a6563d6852f-1188x1205.jpg)

The Journey to Building a Blog in Next.Js and Sanity.io

Well for those that may have been hiding under a rock for the past few weeks, may not know that I recently accepted a new role as Developer Advocate at Sitecore. But I'm still getting to grips of what this new role really means and how it changes my view point a little bit on it's "customer" and who I'm really helping in this role.

Now before I go too far and talk about my role at Sitecore, I first wanted to express how much of a dream it has been to work at the "Mother Ship" as the Sitecore community likes to call it.  I've been working with Sitecore since version 7.2, and over 7+ years.  I've worked with multiple different types of clients and implementations, from household names to companies so large, but no ones ever heard of them, because they do manufacturing or a defense contractor.  I've been fortunate for this journey that I've been on, because it has helped to build a stable and reliable future, and this latest step I always assumed would be inevitable, however I didn't quite see the role I would be taking with Sitecore.

A Developer Advocate position where my primary customer moving forward is not a company with thousands of employees but now instead a customer that is a developer trying to use the products that my company builds.  Now I have to ask, if I was a developer using Product A, does the documentation, sample code, videos etc., truly detail the journey needed to implement this correctly.  It's about making sure the developer is setup for success.

So what is all the Avocado talk and pictures coming from then? I'm honestly not sure, somewhere along the way of the building of this career, Avocado = Advocate, is my guess to why that exists.  I'm not sure, but I'll stick with it, and because of that, you might be seeing a lot more avocadoes on my online profiles moving forward.

## Rebranding Myself

This new role brings a unique opportunity to rebrand myself, shifting away from the pure focus of Sitecore and my previous Sitecore handles.  Sitecore and/or my boss is supportive of this change.  Not because they are against the "Sitecore" alias in my old account logins, but because this starts to build my own brand that can adapt to any current and future possibility.

## New Personal Site

With the rebrand, I'm shifting away from "sitecoremaster" and therefore the domain I previously owned will come with that.  The new site is a custom built application (more on how it's built and the code behind it coming soon), but the days of using Word Press are over.

The new site will also have a lot more than just blog posts moving forward.  It's still a work in progress, but hopefully as I find time, I'll introduce other types of content, including POCs from Github, general guides, video content and short snippets.

## Moving forward

So what's next for me?  Well more of the same, but a lot more of it.  Someone mentioned to me, when I got the role, that I would stop contributing to my YouTube or that my contributions would change.  But honestly, this role is going to take a weekend hobby and amplify it.  Everything I could produce in 5 to 10 hours a week sprinkled in throughout the year, is now a 9 to 5 focus, to not only produce content on Sitecore but also develop my own brand, and focus on topics that are cool and exciting!

Hi, I'm Dylan

Insight Categories

Latest Posts