Yeah this is a killer app for mcp servers. My puppy has food allergies and the vet asked me to track his eating and pooping. I ended up building an mcp server to do this data entry and now I track his activity and planning to track also his training progress. It's very different when you can just tell your model "he ate 2 cups of his kibble" or "we practiced stay for 5 minutes" vs doing tedious data entry. As a bonus this helps my partner and me coordinate dog care so we can have fewer conversations about the dog

A long time ago, I introduced dogstatsd at Airbnb. We had already been using vanilla statsd (with no tag support -- cardinality lived in the metric name!) and this was a low cost migration. More than a decade later, I'm assuming it was difficult to track down and refactor all the places that statsd calls were emitted and using OTLP was an easier route. This is a great example of how technical decisions compound over time.

So is Victoria metrics?

Submodules work fine but yeah, it's frustrating that lfs is taking so long. But there seems to be some momentum recently https://github.com/jj-vcs/jj/pull/9068

The git compatibility page states that submodules are not supported

https://docs.jj-vcs.dev/latest/git-compatibility/

What "not supported" means with submodules specifically is that jj doesn't have commands to manage them. You can use git commands to manage them, and it does, in my understanding, work. There's just no native support yet.

This is sort of similar to how you can create lightweight tags with jj tag, but you need to push them with git push --tags.

> and it does, in my understanding, work.

I use submodules with jj, and jj saves and restores submodule hashes perfectly. What it doesn't do is manipulate the sub-repository from its parent. You can do that yourself using jj or git of course, which is what I ended up doing using a few scripts. The result ended up being more reliable than using git's submodule commands directly.

They can take all the time in the world to implement submodules as far as I'm concerned. jj's implementation of workspaces removes all of the hairs of git's worktrees. git submodule implementation has even more hairs than worktrees. If the jj developers need time to do as good a job on submodules as they did with workspaces, then I say give it to them.

Gotcha, thank you for the context.

I use vimium in Firefox and so my default key bindings are the plug-in ones. I push 't' to create a new tab, for instance. If I want to use the website key bindings I have to to into "insert mode" ('i'), or I opt into specific keys by site.

I do like when websites use ctrl-k -- it means nothing to my plug-in so websites always get it, plus it helps with key binding discovery.

Share your private thoughts and gratitude with your private group, plus the good people at grateful.so, their partners, their service providers, the processor of os notifications, anyone who buys the assets of grateful.so once it goes under, plus any script kiddie who cares to point an LLM at the vibe coded server base...

Damn I'm jaded by our industry...

Yes absolutely this. I've put so much effort into making sure I tick all the boxes and yet I constantly wonder if my email is getting delivered. This feels anti competitive to me. It's Google constantly telling me, give up, you know deep down you should just use Gmail.

I think Gmail doesn’t want you to use their service for sending email; they want you to have to advertise ‘with’ them.

we switched email providers from our all-EU stack to gmail... just as a last desperate attempt at not being marked as spam for actually sending low volume (crazy, right).

well, now we're stuck with gmail for a year, and no, it haven't improved anything!

Oh I made one of these once! In mine you play against other people. https://1dchess.igor47.com/

Oh cool I used to use https://web.hypothes.is/ for this but they never had a good Firefox extension so I stopped. How do you annotate with friends using Margin? Does everyone need to be on the same at proto server?

All the examples are fetching data from a server, and in such cases I think tanstack query already does all the hard part. I feel like people under-use react query and put too much state in their FE. This might be relevant if your app has some really complicated interactions, but for most apps they should really be a function of server, not client, state. Of course this exact reasoning is why I moved off react altogether and now use htmx in most of my projects

It's not just react query, you can make a quick useFetch and useMutation hooks (or claude can), it's not that complex. If you don't need more advanced features (eg caching), you can easily cut down on 3rd party dependencies.

    import { useState, useEffect } from "react";

    function useFetch(url) {
      const [data, setData] = useState(null);
      const [loading, setLoading] = useState(true);
      const [error, setError] = useState(null);

      useEffect(() => {
        const controller = new AbortController();

        fetch(url, { signal: controller.signal })
          .then((res) => res.json())
          .then((json) => {
            console.log("Data:", json);
            setData(json);
          })
          .catch((err) => {
            if (err.name !== "AbortError") {
              console.error("Fetch error:", err);
              setError(err);
            }
          })
          .finally(() => setLoading(false));

        return () => controller.abort();
      }, [url]);

      return { data, loading, error };
    }







    function App() {
      const { data, loading, error } = useFetch("https://jsonplaceholder.typicode.com/todos/1");

      if (loading) return <p>Loading...</p>;
      if (error) return <p>Error</p>;
      return <pre>{JSON.stringify(data, null, 2)}</pre>;
    }

Yeah, fetching data from a server in useEffect is a widely acknowledged and documented antipattern.

It's a widely documented anti-pattern, while also not giving a convenient alternative.

Is it? I have never had any issues doing it this way.

This post explains it pretty well: https://dev.to/deveshsangwan/stop-using-useeffect-for-data-f...

I am not convinced. Have been using this pattern for years without issue.

You can lead a horse to water...

I have been drinking water for years. You are trying to tell me water is an antipattern and I should drink gatorade instead. No thanks.

I'm doing no such thing. I'm alerting you to the fact that the owner of the well where you've been drinking has warned that it's not potable and suggested drinking the pure, filtered water instead.

Did you even read the article I linked? If not, please do. If you did read it, and still believe it makes no difference, I can't do anything more to help and will simply wish you good luck and have a nice day.

It wasn't the owner that suggested it. It was some random blogplost that insisted the normal town well that everyone used was no good and you have to use his super special well instead. He points to an incident 6 months ago where someone got drunk and decided to jump into the well. The dude who jumped into the well didn't even say it was the well's fault.

I did read the article linked. I am remain unconvinced. Use effect for data fetching is not "risky", "fragile", and does not cause "subtle, hard to debug problems". This is baseless fear mongering. Claiming Tanstack is the "right" way is incredibly arrogant.