thejeshgn

DNDoodle My DND group has used doodle for ages to schedule our sessions, but it never really worked that great for us. We just didn't need that many features. This was my very first val and honestly, I couldn't be happier with it.

* This val creates a webhook endpoint that receives text messages and sends SMS replies using the TextBelt API. * It uses blob storage to keep track of message history and conversation state. * The TextBelt API is used for sending SMS messages without requiring an API key. * The conversation history is stored as an array of message objects containing sender, content, date, and phone number. * OpenAI's GPT-4 is used to generate contextual responses based on the conversation history.

Newsly inspired by https://kill-the-newsletter.com/ copy your email into a newsletter like substack read the newsletter here / store them into valtown you can set it so you can chat with it or send you alerts or whatever idk

OG image service for https://val.town/v/jxnblk/dotcom – https://jxnblk.com

Feature Flags This val demonstrates a very simple feature flag implementation. There is a const in the file called FLAGS which stores the feature flags defined, fork this val and modify this value to setup your own flags. Defining flags The example FLAGS value is: const FLAGS: Record<string, Flag> = { "flag1": Flag.rollout(0.5), "flag2": Flag.enabled().block("user_123"), "flag3": Flag.disabled().allow("hello@samwho.dev"), }; This demonstrates: flag1 -- a flag that will be enabled for 50% of users (more on how users are defined later) flag2 -- a flag that is enabled for everyone except user_123 flag3 -- a flag that is disabled for everyone except hello@samwho.dev Endpoints There are two endpoints: / -- the root endpoint fetches all flags for the given user. /:id -- fetches just one flag value, given by :id , for the given user. Specifying users By default, the user is determined by IP address. If you want to be more specific, you can pass in the ?userId query parameter to any endpoint and that will be used instead. How it works This val works by hashing the userId and using the resulting value to determine whether a flag should be enabled or disabled. In a 50% rollout, for example, the numeric hash of the userId is taken and divided by the maximum hash value. If the result is less than the rollout percentage, the flag is enabled. This allows for completely stateless feature flags, no database required. To prevent the same users getting features first all of the time, the flag name is prepended to the userId before hashing.