Forem: Robert Tate

AI Wrangling For Devs 101

Robert Tate — Tue, 29 Aug 2023 16:23:55 +0000

Tips for Working Alongside Generative AI Tools

The recent wave of generative AI products in their many forms (Large Language Models, Image Generators, etc.) have sparked a sense of wonder, excitement, and perhaps even fear in the hearts of many.

As a software developer, I've got a lot of existential questions right now. Will I be out of a job in a few years?

And once that happens, will the robot overlords still look kindly upon me?

Hopefully I can point to this article to prove that I made every best effort to educate and prepare the humans for their smooth arrival.

Speaking of which, I was recently tasked with using AI at work and I want to share my learnings. My employer (Asurion - great place to work 😁) recently decided to host an AI themed developer hackathon, that we are calling the "Asurion Code Jam".

The aim of this "jam" will be to provide dedicated work hours for us to try out writing software utilizing new AI tools. Participants will get to learn while building, and we are emphasizing that they don't have to concern themselves with building viable products if they would rather not.

A hackathon all about education and creativity? I'm in! This was a refreshing approach to me, so I decided to volunteer to help plan the thing.

Fast forward a few months later and the code jam is starting to get real. Time to create the teams! In the spirit of the theme, I became tasked to find a way to use AI to group our participants.

The following is an accounting of that journey - using ChatGPT Plus.

To Hallucinate, or Not to Hallucinate?

Thinking about how to approach this, I was pretty confident that giving ChatGPT (even using the GPT-4 model) over one hundred participant entries with multiple properties for each person and asking it to return them in groups would result in unreliable data.

There are many examples in the wilds of the internet that demonstrate erratic responses if large language models are fed too much input (nonsensical or otherwise), so I knew I had to find an option that would allow me to mitigate hallucinations altogether.

We don't want to publish team rosters that includes pretend people, right? That would be awkward.

Enter Code Interpreter

The new ChatGPT Plus code interpreter tool was the solution that made me realize that I could have my cake and eat it too. AI can do the heavy lifting of writing and testing the algorithm to use for team creation, and I gain the benefit of knowing exactly how the teams were produced. At the end of the day, ChatGPT just hands over some code that I can run myself.

I still trust imperative code more than I do magic chat bots (for now), so this felt like a great way to leverage these new tools without compromising data integrity.

My Process

The following was my process for getting teams created:

I downloaded the spreadsheet with all of the participants from the signup form we sent out to everyone, and resaved it as a csv file.
I wrote a simple node.js script to read the csv file, clean it up a bit, and save it as a json file.
Enter ChatGPT Code Interpreter. If you'd like to see our full conversation, check it out here. At every step of the way, I would take the code snippet of ChatGPT's latest attempt, copy it over into VS Code, run it locally, and assess the results of the outputted csv file.

We finally got to a workable solution, but there was a lot of trial and error in getting to the point where the result was exactly what I needed.

IMPORTANT: I did not give ChatGPT any real participant data. If you ever use public facing generative AI sites for work purposes, you need to think critically about what you're providing it. Personally identifiable information (PII) or other sensitive or proprietary data should obviously be a no no.

AI Wrangling Key Takeaways

Here is what I learned, which I pass on to you as key takeaways for wrangling your own AI's:

Be Crazy Specific

Before the thread with ChatGPT that I linked above, there were other much less successful chat threads where I didn't even get close to a workable solution.

The difference? Whenever I provided more details and context, I got closer. When I didn't provide that clarity, ChatGPT filled in the gaps by making whatever assumptions it wanted, without even running them by me! How rude.

One thing I finally tried really helped: adding a requirements list.

So devs: if you are looking to use ChatGPT to help write the code, you need to put on your product owner hats and clearly articulate the desired outcomes (not saying I did that perfectly, but it helped nonetheless).

If you are having trouble clearly articulating your desired outcomes, figure out why. Is there some missing business context? Is there some ambiguity still floating around in the requirements? Is there some complexity somewhere that needs more unpacking?

When you start the process strong by providing an extremely clear initial prompt, your refinement process will shorten.

Speaking of the refinement process...

Switch to Feedback When You're Close

Depending on the complexity of the desired code, the ChatGPT code interpreter is probably not going to give you what you need on the first attempt. But if you gave it clear instructions (see my first tip), it might come close.

If it does in fact come close to a workable solution, it's time to start a feedback loop instead of starting over with a better requirements prompt. Propose a change, ChatGPT takes another crack at it, and you reassess and repeat as needed.

This stage of the process feels a bit like pair programming with a junior developer. They made some mistakes but they are super eager to try again and get it right.

I found through some early trial and error that the process of refining the solution seems to go smoother if you propose one change or fix at a time, and see how ChatGPT responds to it.

Don't Turn On Autopilot

My last tip when it comes to AI wrangling is this: don't turn your brain off.

Initially there were moments where because AI was writing the code, I inadvertently stopped thinking critically about what it was giving me. It gave me a snippet, I tried running it, it didn't work, and so I just started over without incorporating new directions or feedback that were arguably any better.

A strange sense of laziness was taking over. AI can figure out what I need without me actively participating, right?

Wrong. Because I was not taking the time to comprehend the code and refine my own understanding, I was not giving valuable feedback and we were not getting anywhere. This lasted until the novelty of my new partnership had worn off, and then I realized I needed to start reading, debugging, and actively participating.

I think the larger lesson here is that the output of an AI system is only ever going to be as good as the input it receives. So if we as developers are not steering these tools well, we should not expect the tool to make up the difference.

That makes me a little more hopeful that I'll still have a job in the coming years. 😬

Parting Thoughts

As advertised, this is just a 101 course. If you want to get better with asking AI to do your work for you - you'll need to continue experimenting. The developers of tomorrow are going to have to be both wordsmiths and cyberpunks... not just the latter. Hopefully these insights will help as a starting point for the former.

Robert TateFollow

Software Developer doing life in Nashville, Tennessee. I like to write articles about JavaScript, and I try to make them somewhat beginner friendly.

React is great...but you should try Lit.

Robert Tate — Mon, 29 Aug 2022 19:31:58 +0000

Does anyone else out there need a quick break from React? For just a few minutes maybe?

I've been using React for years now, and I miss the days where it felt new and exciting. In my brain, React has gone from a sports car to a minivan. It's still very good at what it does, but I'm a little bored of it. I don't get very excited using it anymore. We've lost our spark, you might say.

So, I thought I would try something new and get Lit for a little while.

You heard me.

So what is Lit? Per the "about" section on their github page: Lit is a simple library for building fast, lightweight web components.

Their slogan is:

If you don't know what a web component is, take a step backwards here and read about web components on MDN.

Put simply, web components are a set of native browser APIs that let you create your own HTML elements. Those elements can do whatever you want them to. Lit is a library that wraps around web components, making them easier to work with. Instead of setting up web components using the native APIs directly, you can use Lit to make Lit Components.

Your next question might be:

That's not what React does at all...so is Lit really comparable?
Can I use Lit to build web apps, websites, and user interfaces, just like I can with React? Is that even what Lit is meant for?

Yes, Lit is comparable to React in many ways. Yes, you can use it to build websites, web apps, and UI's. And yes, it's intended to be used for those things.

It even does some things React can't do (gasp).

Let's start looking at the differences between a React component and a Lit component. I made a silly little component that takes in a string from user input, and spits it out reversed. Imports not included. And just assume reverseString does what it says it does, in both cases.

The React Component:



export default function TextReverser() {
  const [revText, setRevText] = useState("");
  const inputElem = useRef();

  const handleClick = () => {
    setRevText(reverseString(inputElem.current.value));
  };

  return (
    <div>
      <input ref={inputElem} type="text"></input>
      <button onClick={handleClick}>Reverse Me!</button>
      {revText && <h2>{revText}</h2>}
    </div>
  );
}

Here's the same thing as a Lit Component:



@customElement('text-reverser')
export class TextReverser extends LitElement {
  @state()
  private revText: string = '';

  @query('#input')
  inputElem!: HTMLInputElement;

  handleClick() {
   this.revText = reverseString(this.inputElem.value)
  }

  render() {
    return html`
     <div>
      <input id="input" type="text"></input>
      <button @click=${this.handleClick}>Reverse Me!</button>
      ${this.revText && html`<h2>${this.revText}</h2>`}
     </div>
    `;
  }
}

Oh boy! Such wow! So many new things to talk about and look at.

First, Lit uses TypeScript. It's not required, but it's encouraged and it's awesome. It saves you time on some syntax by enabling the use of decorators. It also gives you strong typing. It also gives you code completion.

Why would you not want those things?

Second, Lit components are class based. Less wow, if class syntax is not your thing. But if I had to guess, I would think that Lit will eventually get support for function based Lit components. I mean, you gotta stay with the times.

To compare what's going on...

In React:

I used useState to manage state for the value of revText.
I used useRef to grab a reference to the input element DOM node.
I wrote a handleClick function which gets called when the button is clicked. It reverses the string and sets the new value for revText using setRevText, which causes the component to re-render.
I rendered html by returning JSX. If revText has a value, it displays it in an h2.

In Lit:

I used the @state decorator to initialize some internal state for the component: revText. I access that in other places in the component using this.revText.
I used the @query decorator to grab a reference to the input element DOM node.
I wrote a handleClick method which gets called when the button is clicked. It reverses the string, and reassigns this.revText to that new value. Because this.revText was initialized using the @state decorator, when its value is reassigned, the component re-renders.
I rendered html in the render method of the component, by returning a tagged template literal, by using Lit's html tag function. If this.revText has a value, it displays it in an h2.

So what did we just learn?

They both encapsulate state & behavior.

Lit and React components both generally implement the same concept: encapsulating state and behavior into little interactive UI bits.

Mmmm....little bits.

They are both composable

Lit and React are both component-based. For each library, you can create more complex UI's by composing your components together. I didn't show how to do this in my code examples above, so here's some reading if you want to dig in further:

They are both reactive.

There is a Lit component lifecycle (no virtual DOM required) and there is a React component lifecycle. When the component state changes, the UI reflects that change.

SIDE NOTE: they both can use redux. Check out this article to learn how to set that up for Lit.

Lit is starting to feel pretty similar to React, after unpacking things a little.

So what's truly different about Lit?

Lit is closer to the browser

With Lit, a lot of the heavy lifting is done by native browser APIs, instead of by additional framework boilerplate code that also has to be downloaded.

I really like this, because it makes sense in my head to use things that are already freely available. You wouldn't make your own ice using ice trays if your fridge already had an ice machine, right?

Because of the emphasis towards leaning on what the browser already offers us (web components), Lit is a tiny library - about 5kb when minified and compressed. So if you're worried about page load and interested in browser features, Lit makes a good argument for itself.

Lit is interoperable (can be used in other things)

Because a Lit component is just a web component at the end of the day, you can use Lit anywhere! You can use Lit on its own, or you can slide Lit components into projects that are using any other front-end framework.

This is especially exciting for the purposes of implementing a design system, for instance. In one of my previous jobs I helped work on one specific implementation of our companies design system - the one that was used in our CMS. Folks from other teams that used React had to create their own React based design system implementation. And so on and so forth for all the other frameworks we used, of which there were a good number. So you can imagine there was a lot of developer time spent on rebuilding the same components over and over for different frameworks.

What if you could just implement your design system once? And reuse it everywhere? That's something Lit can offer. If you need to use one of your design system components in React - first build it with Lit. Then, pull that Lit component into React and get going.

For further reading:

Check out this article on how to integrate a Lit component into a React component.
Lit also has a separate package you can use called @lit-labs/react, which provides a utility to make a React component wrapper for a Lit component.

Parting thoughts

The main thing I want you to get from this article: Lit is cool, and you should give it a try! Please hear me when I say this: React is also excellent at what it does, and this article shouldn't be construed as a recommendation to never use React ever again.

Sometimes it's just nice to branch out, is all.

As a developer, learning should be a constant priority. So if you're feeling how I was feeling about React, and want to feel that spark again, I recommend learning Lit! They've got incredible documentation and interactive tutorials, by the way.

Thanks for reading! If you want to read any of my other articles, you can find them at quickwinswithcode.com.

Robert TateFollow

Software Developer doing life in Nashville, Tennessee. I like to write articles about JavaScript, and I try to make them somewhat beginner friendly.

Essential "this" concepts in JavaScript

Robert Tate — Mon, 25 Jul 2022 16:47:00 +0000

Execution context, implicit and explicit binding, arrow functions, and of course, this.

To me, a competent understanding of the keyword this in JavaScript feels just about as hard to master as the final boss in a D&D campaign.

I am not prepared.

My instinct therefore tells me I should write an article on the subject so that I can attempt to move this from my passive vocabulary to my active vocabulary.

Join me on this quest, and let's level up together.

Levels 1–4: Local Heroes

Defining execution context, this, and new.

Before we look at this, it will be helpful to define execution context. MDN describes execution context in this way:

When a fragment of JavaScript code runs, it runs inside an execution context. There are three types of code that create a new execution context:

The global context is the execution context created to run the main body of your code; that is, any code that exists outside of a JavaScript function.

Each function is run within its own execution context. This is frequently referred to as a "local context."
Using the ill-advised eval() function also creates a new execution context.

Each context is, in essence, a level of scope within your code. As one of these code segments begins execution, a new context is constructed in which to run it; that context is then destroyed when the code exits.

Put simply, an execution context is a created space that directly surrounds a block of running code.

A global context is created at the start of a program. Each time a function is invoked, a local execution context gets created and is added to the execution context stack (the call stack).

I see other articles refer to execution context as the "environment" surrounding your block of running code, which makes sense, because it's more than just a location!

An execution context also has custom properties.

These properties are a little different between global and local context, and between different types of local context (functions vs arrow functions vs classes, etc).

Something that every execution context has however, is a property known as this.

So what is this?

Drum roll…

this is a reference to an object.

But what object? Well, that depends. Time to run through some examples to start figuring it out.

In our first simple example, we log the value of this in the global execution context, outside of any function:

console.log(this); // window

In the browser, we see that this equals the window object.

MDN confirms the behavior in this definition:

In the global execution context (outside of any function), this refers to the global object whether in strict mode or not.

SIDE NOTE: In the browser the global object is window. In Node.js, the global object is actually an object called global. There are some slight behavioral differences though. In Node.js, the example above would actually log the current module.exports object, not the global object. 🤷 Let's avoid that rabbit hole for now.

In this next example, we log this inside a function:

function logThisInAFunction() {
    console.log(this);
};

logThisInAFunction(); // window

At first, you might think that this will evaluate to something other than window, seeing as we created a new local execution context upon invoking the function, which the code inside our function runs within.

But as a default (when not using strict mode, another rabbit hole 🤷‍), unless explicitly set (which we will get to), this still references window.

MDN confirms this default behavior:

Inside a function, the value of this depends on how the function is called.

Since the following code is not in strict mode, and because the value of this is not set by the call, this will default to the global object, which is window in a browser.

SIDE NOTE: There is a weird difference in behavior between the browser and Node.js in this second example. In the browser, this equals window, but in Node.js, this equals global this time, instead of the module.exports object. This is due to the difference in how Node.js handles the default value of this between global and local contexts.

The next example expands on this having a different value based on how the function is called:

function logThisInAFunction() {
    console.log(this);
};

const myImportantObject = {
    logThisInMyObject: logThisInAFunction
};

logThisInAFunction(); // window

myImportantObject.logThisInMyObject(); // myImportantObject

When we call logThisInAFunction() and myImportantObject.logThisInMyObject(), the same function is ultimately being invoked. However, the value of this is not the same for the two invocations. MDN again eloquently describes:

When a function is called as a method of an object, its this is set to the object the method is called on.

Put simply, if you call a function as a method of an object, that object is going to become the value for this instead of the global object. In this way, we are implicitly binding the value of this to an object of our choosing.

The next example looks at how this behaves for classes:

class MyAwesomeClass {
    constructor() {
        console.log(this);
    };
};

const awesomeClassInstance = new MyAwesomeClass(); // MyAwesomeClass {}

When creating an instance of a class using the new keyword, a new empty object is created and set as the value of this. Any properties added to this in the constructor will be properties on that object.

As MDN puts it:

The behavior of this in classes and functions is similar, since classes are functions under the hood. But there are some differences and caveats.

Within a class constructor, this is a regular object. All non-static methods within the class are added to the prototype of this.

Relatively straight forward.

Before we level up…

Hopefully this is starting to sink in. Having already talked about implicit binding, let us explore the next level: explicit binding.

Levels 5–10: Heroes of the Realm

Defining call, apply, and bind.

Earlier we saw how we can take a function, add it as a method to an object, and when we invoke that method, that object implicitly becomes our new value for this.

Now we want to learn how to explicitly set the value of this when invoking a function. We can do that with a few different methods: call, apply, and bind.

First, an example using call:

const wizard = {
    class: 'Wizard',
    favoriteSpell: 'fireball'
};

const warlock = {
    class: 'Warlock',
    favoriteSpell: 'eldrich blast'
};

function useFavoriteSpell(name) {
    console.log(`${name} the ${this.class} used ${this.favoriteSpell}!`);
};

useFavoriteSpell('Bobby'); // Bobby the undefined used undefined!

useFavoriteSpell.call(wizard, 'Bradston'); // Bradston the Wizard used fireball!

useFavoriteSpell.call(warlock, 'Matt'); // Matt the Warlock used eldrich blast!

The first time we invoke useFavoriteSpell, we have undefined values. this has defaulted to referencing the window object, and the properties class and favoriteSpell do not exist on window.

The next two times we invoke useFavoriteSpell, we are using call to assign the value of this to the object of our choosing, and also invoking the function.

That is what call does! The first argument of call is the object you want this to equal, and the subsequent comma separated arguments are the function arguments.

You can read more about call here.

The next method we will look at is apply. No additional code example is necessary to understand it, in my opinion. The main difference between call and apply is this:

call accepts function arguments one by one in a comma separated list.
apply instead accepts all function arguments as one array.

Outside of some other small differences, they do the same thing. You can read further about apply here.

Finally, we have bind:

const wizard = {
    class: 'Wizard',
    favoriteSpell: 'fireball'
};

const warlock = {
    class: 'Warlock',
    favoriteSpell: 'eldrich blast'
};

function useFavoriteSpell(name) {
    console.log(`${name} the ${this.class} used ${this.favoriteSpell}!`);
};

useFavoriteSpell('Bobby'); // Bobby the undefined used undefined!

const useFavoriteWizardSpell = useFavoriteSpell.bind(wizard);

useFavoriteWizardSpell('Bradston'); // Bradston the Wizard used fireball!

const useFavoriteWarlockSpell = useFavoriteSpell.bind(warlock);

useFavoriteWarlockSpell('Matt'); // Matt the Warlock used eldrich blast!

Instead of setting the value of this and also invoking the function, calling bind on our function just returns a new function, whose this value is now equal to the object we passed as the argument of bind.

We can then call our new function whenever we want, and the value of this has already been set.

Before we level up…

So now we know about execution context, this, and how to set a value for this both implicitly, and explicitly with call, bind, and apply.

What else is there? To be honest, there is a lot. But let's focus on one thing at a time, and move on to the relationship between this and arrow functions.

Levels 11–16: Masters of the Realm

How arrow functions affect this.

Earlier, I said that every execution context has a property known as this. The behavior with arrow functions is a little different, however.

While the local execution context created by invoking an arrow function does still have a value for this, it does not define it for itself. It instead will retain the value of this that was set by the next outer execution context from where the function was invoked.

For example:

const logThisInAnArrowFunction = () => {
    console.log(this);
};

const myImportantObject = {
    logThisInMyObject: logThisInAnArrowFunction
};

logThisInAnArrowFunction(); // window

myImportantObject.logThisInMyObject(); // window

We see when we call myImportantObject.logThisInMyObject() that even though a new local execution context was created, this is going to get its value from the next outer execution context. In this case, it is the global execution context. Therefore, this remains a reference to the window object.

Here is another example that hopefully will drive it home:

const myImportantObject = {
    exampleOne: function() {
        const logThis = function() {
            console.log(this);
        };
        logThis();
    },
    exampleTwo: function() {
        const logThis = () => {
            console.log(this);
        };
        logThis();
    }
};


myImportantObject.exampleOne() // window

myImportantObject.exampleTwo() // myImportantObject

In this example we have two methods we call from myImportantObject: exampleOne() and exampleTwo().

When we call myImportantObject.exampleOne(), we are invoking that function as a method of an object, and therefore, this equals myImportantObject in that local context.

However, inside that function, we define another function and then execute it.

As previously mentioned, unless explicitly set, and unless the function is being invoked as a method of an object, this references the global object, window. Therefore, we see window logged.

When we call myImportantObject.exampleTwo() however, something different happens. The first part is the same: this equals myImportantObject inside exampleTwo. Next, we define an arrow function and then execute it. The difference is, the arrow function does not define its own value for this! It instead retains the value of this from the next outer execution context, which in this example, was the local context created by myImportantObject.exampleTwo(), where this equalled myImportantObject. So that is what we see logged.

Before we level up…

Arrows functions differ from regular functions in plenty of other ways. If you want to read more, check out MDN's page on the topic.

If you have made it to this point in the article, it should hopefully mean that things are starting to sink in. Take a moment to relish in your achievement.

There's only one section left. Let's dive in.

Levels 17–20: Masters of the World

Callbacks.

Before I started writing this article, I thought the last section was going to be the most difficult to tackle. In the past, examples of how this got its value in callback functions confused me.

With the context I now have, it no longer feels like callback functions add any more complexity to how this works. We just need to consider what we already know about execution context, and how we invoke a function.

I guess the final boss is starting to look a little more beatable 😁.

Here is an example of using this within callback functions. See if you can guess what the values logged for each will be:

function higherOrderFunction(callback) {
    const myImportantObject = {
        callMyCallback: callback
    };
    myImportantObject.callMyCallback();
};

function callbackFunction() {
    console.log(this);
};

const callbackArrowFunction = () => {
    console.log(this);
};


higherOrderFunction(callbackFunction);
higherOrderFunction(callbackArrowFunction);

Starting with our first function call (where the argument is callbackFunction):

higherOrderFunction is invoked, and creates a local execution context. Because it is not implicitly or explicitly set, this defaults to window.
Our callback function is invoked inside higherOrderFunction via myImportantObject.callMyCallback(). Because our callback is not an arrow function, the created local execution context defines its own this. And, because that function is being invoked as a method of myImportantObject, this equals myImportantObject.

Next, let's look at the second function call (where our argument is callbackArrowFunction):

higherOrderFunction is invoked just as before. Same outcome: this equals window in that local context.
Our callback is once again invoked inside higherOrderFunction. This time, because our callback is an arrow function, it does not define its own this. So even though it is being invoked as a method of myImportantObject, this retains the value of the next outer execution context, which was window.

The moral of the story is, callback functions add complexity only in the sense that you have to consider how (and also where for arrow functions) the callback is being invoked.

But we were considering that already!

The difference is that callback functions are passed as arguments to other functions, and so where and how they get invoked is a little different.

Parting Thoughts

Hopefully I didn't lose you at some point 😅.

As a developer, I am always trying to continue my education - and I recognize that there is still so much I do not know.

this is a big subject, and I am sure that there are aspects of the concept that I missed, or examples and explanations that could be improved. Let's help each other by trying to figure out what those were! Feel free to leave a comment, and let me know if this article helped you, and/or what could have been improved.

Thanks for reading! 😄 Check out some of my earlier articles at quickwinswithcode.com.

Forem: Robert Tate

AI Wrangling For Devs 101

Tips for Working Alongside Generative AI Tools

To Hallucinate, or Not to Hallucinate?

Enter Code Interpreter

My Process

AI Wrangling Key Takeaways

Be Crazy Specific

Switch to Feedback When You're Close

Don't Turn On Autopilot

Parting Thoughts

Robert TateFollow

React is great...but you should try Lit.

They both encapsulate state & behavior.

They are both composable

They are both reactive.

Lit is closer to the browser

Lit is interoperable (can be used in other things)

Parting thoughts

Robert TateFollow

Essential "this" concepts in JavaScript

Execution context, implicit and explicit binding, arrow functions, and of course, this.

Levels 1–4: Local Heroes

Before we level up…

Levels 5–10: Heroes of the Realm

Before we level up…

Levels 11–16: Masters of the Realm

Before we level up…

Levels 17–20: Masters of the World

Parting Thoughts

Resources