Blog posts by HTTP 418

Dialing-in Your AI with Optimizely Feature Experimentation

Mon, 13 Nov 2023 17:17:00 GMT

If you're in technology, AIs are everywhere nowadays. At work, I use an AI to help me make proofs of concept, sometimes in communicating with other AIs. At home, I use Google's Bard to help with those day-to-day mental chores such as meal planning. Even at play, when indulging in some Gran Turismo there's an AI to race against. I can't do anything about the AIs I use more casually (aside from being aware of them). At work though, I have some control! When interfacing with an AI through an API, you're given the opportunity to tweak parameters or try the same query with different contexts before getting a response from your AI. And what better to help judge your user engagement with an AI than Optimizely's Feature Experimentation!

Here I'll be working with OpenAI's API along with their client package from nuget in order to simplify some rather ugly setup. I'll include an HttpClient version of the call at the end of the post so you can see the details involved.

In this demo, I'll be switching the AI model that my application uses, but this approach can be used on any of the parameters sent to the AI. Your basic OpenAI API call follows this format:

            client = new OpenAIAPI(apiKey);

            var parameters = new CompletionRequest
                {
                    Model = "gpt-3_5-turbo",
                    Prompt = promptText,
                    Temperature = 0.7,
                    MaxTokens = 100
                };
            var response = await client.Completions.CreateCompletionAsync(parameters);

            generatedText = response.Completions[0].Text;

This should look familiar to any developer that's used a client wrapper for an API. The connection details are handled by the client, but the business-end of the of request is the CompletionRequest parameters. Here's we're able to select the AI model we want to query against, as well as supply the context/prompt, as well as other details relevant to the AI setup.

But what if we aren't sure that the model is the best fit for our purposes? Wouldn't it be nice to try out a couple different models and track metrics on them? Here's Feature Experimentation to help with that!

What I've done is set up an experiment that either sends the user's query to ChatGPT 3.5 or the Davinci model:

From there, we configure the Optimizely client back in our solution:

        optimizely = OptimizelyFactory.NewDefaultInstance(Configuration.GetValue<string>("Optimizely:SdkKey"));

        user = optimizely.CreateUserContext(numGen.Next().ToString());

        user.TrackEvent("Engaged_AI");

Now we can make our decisions on whether the user gets to interact with the chosen AI and which model they're conversing with, using Optimizely's Feature Experimentation.:

var decision = user.Decide("ai_model");

if (decision.Enabled)
{
    var ai_model = decision.VariationKey;
    var parameters = new CompletionRequest
        {
            Model = ai_model,
            Prompt = promptText,
            Temperature = 0.7,
            MaxTokens = 100
        };
    var response = await client.Completions.CreateCompletionAsync(parameters);

    generatedText = response.Completions[0].Text;
}
else{
    generatedText = "AI is not enabled for this user";
}

According to the experiment I've set up, 90% of my users will have the opportunity to interact with the AI, if they do their query will either be sent to ChatGPT 3.5 or Davinici and I'll be able to judge the level of engagement between my users and my AI.

Here is also where you can add more context to the prompt to give the AI a better understanding of the query. This could help your AI understand its starting point, such as "you are a customer service agent for company A."

Now as you introduce AI into your applications, you can see how both Feature Flagging and Feature Experimentation can help you evaluate your approach to AI.

Databases from the Future: What is Database Version 954?

Mon, 16 Oct 2023 17:08:00 GMT

Have you started up a new Optimizely site, and prepared your database only get to this error message?

Reading the error message itself, you'll see that the created DB version is at 957 where the current version of Optimizely, at the time of this writing, is 904.

Where did this come from?
How do I put my database in a time machine and bring it back to the present?

The good news on both parts of this manageable with a visit from Dr. Emmett Brown. The first question: "Where did this come from?" is a versioning issue. SQL Server 2022 (v16) will create future database if you simply run your database creation against a SQL 2022 instance. This will occur if your default instance is SQL 2022 regardless of how you go about generating your database.

So, that's how it happens, now how do you create a database that is ready now, instead of a database from the far future? This is where Visual Studio and SQL Server Object Explorer come in handy. Visual Studio installs a database instance for itself, which you can see when you pull up the SQL Server Object Explorer:

You can already see from the screenshot that this is a SQL 2019 instance as it is v15. Right clicking this instance and selecting New Query will open up a new SQL command tab. Here it is a simple matter of running your creation script to create your blank database so Optimizely can configure it on startup.

Fixing Missing Token in For This {0}

Fri, 13 Oct 2023 16:07:00 GMT

I recently encountered an issue where my non-content blocks (site settings, categories, etc.) were producing a "For This" folder with a missing token. This missing token appeared in custom content, as well as add-ons like Geta Categories.

For custom content, two things are required to get a value into that empty token: an XML file under the lang folder, and UIDescriptor. In order to fix an add-on like Geta Categories (which already has the UIDescriptor baked-in), all that is needed is an XML file under the lang folder. This is a pretty simple XML which simply denotes the content type in question and the name you'd like to give it. Like so:

<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<languages>
  <language name="English" id="en">
    <contenttypes>
      <CategoryData>
        <name>Working Category! </name>
      </CategoryData>
    </contenttypes>
  </language>
</languages>

Simply adding the file for Geta Categories will resolve the issue there, since they've already included the required UIDescriptor in the package. The result will look like this:

For your own custom types, the already-mentioned UIDescriptor is also required. This is a simple bit of code to notify Optimizely what to fill in for what tokens. The XML can be expanded to include multiple types, each with their own user-defined name node.

<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<languages>
  <language name="English" id="en">
    <contenttypes>
      <SettingsBase>
        <name>Setting</name>
      </SettingsBase>
      <CategoryData>
        <name>Category</name>
      </CategoryData>
    </contenttypes>
  </language>
</languages>

The UIDescriptor is few lines of code that inherit from the generic UIDescriptor<T> where T is the content type we want to target. As you can see in the XML the parent node of name should be the content type name so that Optimizely can pair it up correctly.

    [UIDescriptorRegistration]
    public class SettingsBlockFolderDescriptor : UIDescriptor<SettingsBase>
    {
        public SettingsBlockFolderDescriptor()
        {
            IsPrimaryType = true;
        }
    }

With both pieces in place, we'll now see our XML-defined name appear instead of the empty token, {0}:

Is Your Postman Delivering Too Much? Postman Alternatives

Tue, 28 Feb 2023 21:21:00 GMT

I've been a long-time user of Postman, and I've seen it grow throughout the years. All I need from Postman is a REST client to check my API endpoints. Recently though, as I opened Postman and had to click through three offers for services I will never use, I started thinking that I should take a survey of alternatives with less bloat and take them for a test drive.

Below are the services I found that serve the purpose of simply sending requests to an API among a few the other features that went into consideration were:

Request History

The ability to recall previous requests was second only to sending requests in my priority list while evaluating clients.

Post Response Testing

If doing repeated testing against an API having the ability to test the responses via JavaScript in the client can save a lot of time.

Collections

To go hand-in-hand with post-response testing, collections are a great way to organize requests if you're working with multiple APIs, such as I do as a consultant. In previous lives, I worked with only API, so in those cases collections become less important.

Hoppscotch.io

Hoppscotch is a simple web-based interface client, with an available Universal Windows app for download. Unfortunately, Hoppscotch does not inherently support local testing, but there is a browser extension that fills the gap. Once I installed that the extension, I found Hoppscotch quite easy to use. It has a minimal interface, which I appreciate opposed to Visual Studio's cockpit's-worth of buttons, dropdown menus, and tools that 80% of us only have a vague idea of its purpose. The desktop app even has a "Zen Mode" which removes the text labels from the side menu. (I do this with my phone apps too, my partner has no idea how I'm able to find anything!) Testing in Hoppscotch is accomplished through their own assertion functions and runs only one test script per request. This can make for some difficult test development if you need to test several pieces of the response. Essentially, you'll need to AND all your test results together, meaning a failing test could leave you scratching your head for a bit. Overall, Hoppscotch fills the role of "just an API client" very well. If you're doing local testing, you'll have to deal with the additional setup, and having an extension attached to your browser which your IT security folks may not be a fan of. If you're willing and able to use the extension, Hoppscotch is a great overall experience. 8/10

Hoppscotch.io as a UWP, clean & simple

Same as above, but Zen Mode Activate!

Insomnia

I was turned onto Insomnia by a colleague and as an insomniac myself, I felt I had to give this client a try! Insomnia is one of the more robust clients I test drove. It sits at the cusp of usability and bloat, in my opinion. Insomnia offers a full-featured experience, included my top three priorities: history, collections, and testing. I was quite impressed with Insomnia's testing feature. Using the Chai API for assertions, I was able to assemble simple tests within seconds. Even given my zero previous experience with Chai, I was able confirm various pieces of the returned data without having to curse once! Any developer that works primarily in the backend, knows exactly what a blissful experience it is not having to curse at your JavaScipt to get it to work can be. I digress, Insomnia's testing capabilities extend beyond individual tests and allow you to run an entire suit of tests at once. This feature makes for fantastic regression testing, as you can fire off multiple requests to different endpoints, each getting their own response to run the test script against. If you're willing to put in the work, Insomnia can even chain requests for testing, taking values for the previous request and supplying them to the next. Insomnia, despite beginning to get into the territory of "features I'll never use", is the best well-rounded Postman alternative I encountered during this venture. 9/10

Clean, simple, powerful

Sweet testing suite!

Thunder Client

Thunder Client is another tool in the Swiss Army knife of development that is VS Code. I love VS Code, I'm always on the lookout for ways to get more use out of it. So, Thunder Client fits right into my daily use. Thunder Client lacks some of the features that I've taken for granted in the previous two clients. It lacks the ability to bulk edit query parameters and does not provide easy GraphQL queries. If those are important to you, maybe Hoppscotch or Insomnia are a better fit for you. That out of the way, Thunder Client supports all my big three wants in a client. Thunder Client's testing is a simple dropdown query builder. With a few selections, given limited functions, you're able to quickly put together tests to examine components of the response. However, if you're looking to do more advanced testing, again you'll need to go elsewhere as Thunder Client doesn't provide access to the JavaScript generated from the dropdown selectors. Thunder Client is a great way to fire off requests if you've already got VS Code open and just need to get to that breakpoint to see where that null reference is popping up. I wouldn't suggest it as a tool to cover all your documentable cases, but it's a handy debugging tool attached to an application you likely already have open. 7/10

Thunder Client in all its glory

Simple test generation!

Honorable Mention

Yaade

Yet Another API Development Environment (YAADE) is a container-based API client that you can simply pull the container, install a browser extension, and you're off and running. This brings the convenience of a web-based approach to your local environment. Unfortunately, Yaade does not appear to support testing JavaScript on return at this time. However, it does provide for collections and history. I don't use containers in my day to day, and I didn't want to get involved with dealing with containers at this time, so I gave this one a pass. If you use Yaade, or are set up to try it out, post a comment below and let us know how it is!

Disclaimer: The above views and opinions are the author's alone, and a not endorsed by the covered applications, the author's employer, or any other associated entity.

You Just Got Vectored! SVG Image Formats

Fri, 03 Feb 2023 13:44:00 GMT

If you're reading this, then you've come across a need that nearly all Opti developers encounter in their careers; You need to display a vector image format (SVGs and the like) properly, the <IMG> tag just isn't going to cut it anymore. Post like this are a right-of-passage for Opti bloggers.

"So," you think "if there are so many other blogs out there on the topic, why should I read yours?" Firstly, you enjoy my familiar and conversational tone of writing.

Cary Elwes does the English accent, I do the nerd stuff.

Second, you've already come this far, you might as well finish as this point, it's not long, I promise. To that point, and most importantly, I've seen some complex solutions out there, this one is a quick and simple implementation. 100% Guarantee!

The VectorFile class:

[MediaDescriptor(ExtensionString = "svg")]
    public class VectorFile : ImageData
    {
        public override Blob Thumbnail { get => BinaryData; }

        public virtual string XML
        {
            get
            {
                try
                {
                    var blob = BinaryData;
                    var xmlDoc = new XmlDocument();
                    xmlDoc.Load(blob.OpenRead());

                    return xmlDoc.InnerXml;
                }
                catch
                {
                    return "";
                }
            }
        }
    }

This delightful little class will extract the thumbnail for previews and place the image in an XML document that can be inserted into a view as an <SVG> tag. You can see from the MediaDescriptor attribute that we're only allowing .SVG files here. This list can be expanded as needed. This is where you can also supply further properties regarding your SVG in the class, it's just content after all!

The VectorFileController class:

    public class VectorFileController : AsyncPartialContentComponent<VectorFile>
    {
        protected override async Task<IViewComponentResult> InvokeComponentAsync(VectorFile currentBlock)
        {
            return await Task.FromResult(View("~/Features/Media/_vectorFile.cshtml", currentBlock));
        }
    }

The should look familiar to CMS12 block development, just your run-of-the-mill controller. No tricks, no fills.

The VectorFile view:

@model VectorFile

@if (Model != null)
{
    @((MarkupString)Model.XML)
}

A lot of devs would have you use @Html.Raw to put the SVG code on the screen, but with the MarkupString struct. We on less shaky ground here because MarkupString is parsed in an HTML or SVG format, rather than trusting that the silly SVG you grabbed off Pinterest for that company party doesn't have some nasty embedded code.

Now, on the next upload to your Media folder, any SVG file should appear as a VectorFile instead of an ImageFile! (You did take the .svg extension out the MediaDescriptor of your raster image class, right?)

Told you it would be short and simple! Happy coding Opti-mists!

Config-Per-Site in Multi-Tenant Environments

Wed, 11 Jan 2023 23:41:00 GMT

Recently, a task was given to me at work where we needed a multisite configuration. We all know that multi-environment is as easy as appsettings.<environment_name>.config. What about in multi-tenant environments? You can't have appsettings.site1.config and appsettings.site2.config in your site! Well, not without a little extra work...

Allow me to introduce AddKeyPerFile; this handy little function that you set up in your Program.cs will enumerate the files in a directory and add them to your Configuration.

"Alright!" you must be thinking "Show me how this miracle function works..." Well, let's get to it! First, you'll want to identify the config sections that will be unique to each site and put them in their own folder. I do this by site name because it makes the most sense by our conventions, if something else works for your practice, these names aren't set in stone.

Now, in order to suck those values into your config, there's one simple line to add to Program.cs:

 var configBuilder = new ConfigurationBuilder()
 .SetBasePath(Path.GetDirectoryName(Assembly.GetExecutingAssembly().Location))
 .AddJsonFile("appsettings.json", false, true)
 .AddJsonFile($"appsettings.Environment.GetEnvironmentVariable("ASPNETCORE_ENVIRONMENT")}.json", true, true)
 .AddJsonFile("appsettings.local.json", true, true)
 .AddJsonFile($"appsettings.{Environment.MachineName}.json", true, true)
 .AddKeyPerFile(Path.Combine(Directory.GetCurrentDirectory(), "SiteConfigs"), true, true)
 .AddEnvironmentVariables();

AddKeyPerFile expects at least a fully qualified path to the config folder, no short cutting this. The following two bools indicate if the file is optional, and to reload the file if it changes, respectively and these are optional.

So, now that we've got them in the Configuration, how do we get them out? Simple:

_configuration[$"{siteName}.json"];

This is where your file naming convention comes into play, you need to be able to look them up by name in Configuration, so make sure it's something you can work with. However, there's a snag with this... We get the entire contents of the file as a value, so we'll need to deserialize that into something a bit more usable:

var jsonSettings = JsonConvert.DeserializeObject<StyleSettings>(_configuration[$"{siteName}.json"] ?? string.Empty);

And there we go; we've got access to Configuration values on a per-site basis.

The 1001st Piece in your 1000 Piece Puzzle: .NET Default Interface Functions

Mon, 28 Nov 2022 18:55:00 GMT

I was recently working with a client who wanted a reasonably large subsystem added to Optimizely that would add automated management to their content. While cutting the code for this, I found myself writing similar code across multiple classes. The reason why I had to write it that way was: 1) The client was currently on CMS11 and didn't have access to newer language features; 2) The hierarchy of the classes prevented me from inserting a common ancestor. Thankfully, .NET has expanded the functionality of interfaces, so we can take advantage of those within Optimizely.

With .NET 5, Microsoft introduced default implementations on interfaces. What this means is that function bodies can be included in the interface definition itself. Resulting in all classes that implement the interface can use the default implementation, or override it with custom logic. Enough text, lets code!

Original Interface

The following code is something that we'd create for an Optimizely experiment:

using OptimizelySDK;
using OptimizelySDK.Entity;

namespace Teapot.Interfaces.Services
{
    public interface IExperimentation
    {
             
        public OptimizelyUserContext CreateUserContext(UserAttributes userAttributes = null, EventTags eventTags = null);
        public string GetUserId();

        public void TrackEvent(string eventKey);
    }
}

Not much to see here, it's just like every other interface you've ever written.

Interface with default implementation

With this update to the interface, I've added default code to the GetUserId function. This will do a couple things: Centralize repeated code (remember to keep it DRY), and this function does not have to be implemented separately when a class utilizes the interface.

using OptimizelySDK;
using OptimizelySDK.Entity;
using Perficient.Infrastructure.Interfaces.Services;
using System;

namespace Teapot.Interfaces.Services
{
    public interface IExperimentation
    {
             
        public OptimizelyUserContext CreateUserContext(UserAttributes userAttributes = null, EventTags eventTags = null);
        public string GetUserId(ICookieService cookieService)
        {
            var userId = cookieService.Get("opti-experiment-testA");
            if (userId == null)
            {
                userId = Guid.NewGuid().ToString();
                cookieService.Set("opti-experiment-testA", userId);
            }

            return userId;
        }

        public void TrackEvent(string eventKey);
    }
}

As with all interface functions, the default implementation can be overridden as needed if there is an exception to your standard usage.

Using default implementation

To call the default implementation in the interface, the object needs to be cast to the interface type, otherwise the runtime will look for an overridden version of the function on the implementing object.

return _featureExpermentation.CreateUserContext((this as IExperimentation).GetUserId(_cookieService));

Since this can create some ugly code if the default implementation is often called. The can be remedied with a little syntactic sugar in the class leveraging the interface:

        public string GetUserId()
        {
             return (this as IExperimentation).GetUserId(_cookieService);
        }

Thoughts

I wanted to post this earlier, but I spent some time considering where this paradigm shift sits in my current Opti architecture. "This doesn't fit the traditional view of Domain-Driven Design!" was my first thought. As much as I was excited for this new language feature, I thought it was going to be the stork-beak pliers in my coding toolbox. As I tried a few things out and tinkered around with default functions, I thought back to all the times I wrote functions in services that stood alone, no arguments or services required to do the job. These are the little places that I think a default interface implementation can fill in, alleviating some of the bloat (we'll never get all of it) from services.

My rule of thumb from here has been that if a method is acting on the object with no outside dependencies, maybe it should be a default function on the appropriate interface.

Optimizely Gets More (Case-)Sensitive

Thu, 25 Aug 2022 15:25:00 GMT

As Windows developers, we don't always have to pay attention to capitalization when dealing with paths and URIs. With CMS12, Optimizely has started deploying to a Linux container for hosting sites. This means that deployed sites (and developers!) will have to pay attention to capitals in references. Inconsistent capitalization can cause 404 errors in unexpected places. Thankfully there's a few ways to handle that!

The worst part of this is that developers won't be able to find these issues until deployed to Azure, with Windows, being case in-sensitive and all. Once named, files and folders can be difficult to change in git. Below are some ways to help rename your files so that they'll play nicely in Linux.

Rename via Git mv Command

One way to update capitalization is by the git mv command. In you git command shell:

git mv <source> <target>

This command will rename a file or folder, however it still runs in the context of Windows. If you want to simply change change capitalization you'll have to use an intermediate name due to the previously mention case-insensitivity of Windows, otherwise you'll get an error message from git. For example using the Scripts folder, in order to get the name to simply lower-case the following command sequence has to be run:

git mv Scripts scripts-lowercase 
git mv scripts-lowercase scripts

Changing name directly in repo

This is perhaps the most straight-forward way to fix capitalization. If available, you can simply rename the files that need to match capitalization. I work in Azure DevOps, where this changes is as simple as hitting the kebab menu and select "rename".

Updated file names will carry-through a pull request, giving you proper naming on your master branch when completed.

Update your git configuration

Perhaps the best way to enforce case-sensitivity is to update your git configuration to be case-sensitive in the first place. To do this, run this command in your git shell:

git config core.ignorecase false

This command will force git to pay attention capitalization on commits. If you want to only enforce this restriction do your local dev environment, you can add the --local argumment to the command. Doing this will cause only your commits to enforce capitalization, so other devs are not impacted.

Unfortunately, if trying to update an existing repo this method can leave artifacts behind in your repository that will need to be cleaned up. These artifacts will not show up in your local file system, and will have to be removed via git command with the rm function, or removing the folders directly from your git repo.

And another thing!

If a PR already exists and you're trying to merge capitalization changes into it, this will not update the names on merge. If you cancel/abandon the PR and create a new one, the capitalization changes will then be merged in properly.

This is a prime time to examine your file names and if they aren't inline with your current standards, now is the time to reduce some tech debt rather than create more by carrying bad practice past this point. A future dev (possibly even a future you) will thank you.