All of Me


![🍎🐛](https://padilla-media.s3.amazonaws.com/blog/art/sketches-2025-02-08.jpg)

This guy is already using the M4 chip.


An Apple A Day

Myst Constraints


Harrison Chase with LangChain released [a walkthrough](https://www.youtube.com/watch?v=1A79eYjiBvo&ab_channel=LangChain) of an AI app that handles email triage. For those who have already gotten their hands dirty with the Lang ecosystem, the structure of the graph is most interesting.

On a high level, there's a succinct handling of tool calling. First, A message is drafted in response to an email. From there, a tool may be invoked (find meeting time, mark as read, etc.). Then, the graph can traverse to the appropriate tool.

`draft_message` seems to be the heavy lifter. Tool calls often return to the `draft_message` node. Not unlike other software design, a parent component is ultimately responsible for multiple iterations and linking between child components.

A few other observations:

1. The graph entry point is through a triage node. Their example uses an LLM to determine the next steps based on message context. This can be error-prone, but is likely mitigated by the fact that this app uses human-in-the-loop.
2. There’s a pattern for recovering from bad calls from the LLM. In this case, there is a `bad_tool_call` node that is responsible for rerouting to the `draft_response` node in the event that the agent hallucinates a tool. Another point of recovery!
3. Rewrite Node: Message generation follows two different passes to an LLM. One to write an initial draft (“What do I need to respond with?"), and then a rewrite node. (“What tone do I need to respond with?“) A useful pattern for message refinement.

You can find the [graph code here](https://github.com/langchain-ai/executive-ai-assistant/blob/main/eaia/main/graph.py). And [here is the walkthrough](https://www.youtube.com/watch?v=1A79eYjiBvo&t=1029s&ab_channel=LangChain), starting at the explanation of the graph structure.


LangGraph Email Assistant


Everything about The Cotton Module's future space travel concept album "The Greatest Remaining Hits" is just... _cool_.

I have to point out, in particular, the domain name: [ooo.ghostbows.ooo](https://ooo.ghostbows.ooo). You're probably familiar with cheeky uses of country domains. "Chr.is", for example. It's lovely to see a general top-level domain in action (and an onomatopoeia, no less!)

Do treat yourself to the tap essay. It's a delight.


Oooo~ The Greatest Remaining Hits


I saw the future in action with development containers and Github Codespaces last night! Really great presentation from [Sebastian Steins](https://bas.codes/) and Nicolai Fröhlich from Europe!

The talk dove into [Github Codespaces](https://github.com/features/codespaces) as well as [Development Containers](https://containers.dev/). 

The gist is that moving the development environment to a cloud based host eliminates the friction of downloading packages, walking through the bash script that manages those downloads, and synchronizes all versions between dev environments.

Really interesting process! Nicolai highlighted that one benefit to this would be to have access to higher processing power than what's on your machine. When I was fiddling with modern development as a music teacher, I only had a $200 Chromebook, with miserable performance specs. Would have been great to play with this back then! 🙂

I'm excited to experiment more with these setups!

Development Containers


I'm in a situation where I just implemented dynamic routes at my site directory in Next. Essentially, I have two sources of pages:

1. Albums
2. Blog Posts

They both are rendered on pages with slugs in this fashion:

- chrisdpadilla.com/spring
- chrisdpadilla.com/nextrerouting
- chrisdpadilla.com/acnm

One reason people advocate against this is that the namespace becomes cluttered. It's possible, then, to accidentally have an album and a blog title have the same slug.

Maybe a trite example since I'm a sole operation here — I _should_ be able to catch something like that. _But_ writing an integration test will help me sleep at night knowing that there's no _way_ this would happen on accident.

# Jest

My first step in setting up tests for the site was getting a few End-to-end checks. I've [set up Cypress](/cypressintro) and [written tests that verify the happy path on my site works](/verifybrokenlinks).

Cypress _can_ handle unit tests, but is a bit heavy handed for the solution. Jest is the long time favorite in this department, so I'm opting to bring that into the mix here.

# Writing The Test

I'm modeling my configuration after [the example in the Next.js repo](https://github.com/vercel/next.js/tree/canary/examples/with-jest).

With Jest running, I wrote out the test:

```
import { getAlbums, getAllPosts } from '../lib/api';

test('Verify no conflicting slugs', () => {
  const albums = getAlbums();
  const posts = getAllPosts(['slug']);

  const slugs = {};
  const recurringSlug = [];

  const verifyUniqueSlug = (item) => {
    const { slug } = item;
    if (slugs[slug]) {
      // Fail test
      recurringSlug.push(slug);
    }
    slugs[slug] = true;
  };

  albums.forEach(verifyUniqueSlug);
  posts.forEach(verifyUniqueSlug);
  expect(recurringSlug).toEqual([]);
});

```

To break it down:

1. I'm grabbing my slugs from both albums and posts
2. I'm iterating over both
3. For each slug, I check if it already exists.
4. If so, add it to the `recurringSlug` array
5. Check for an empty `reccuringSlug` array.

Voilà! I can sleep more soundly knowing that there are no conflicting slugs.


Chris Padilla/Blog

On This Day