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

Latest Posts

Getting the GuestRef in the Browser with Sitecore CDP/Personalize

Introduction to the Git CLI - Simple Commands

Become a VSCode Power User while using Project Code Snippets

Configuration of 301 Redirects with Netlify and Next.Js

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

Venturing Into the World of #DevRel