copypaper

I think you're looking for `import 'server-only'` and not "use server";. Use server exposes functions as endpoints to the client. I.e. they are simply obfuscated api endpoints without boilerplate. Their main use is for mutations such as a form submission from the client.

Since pages are, by default, SSR, you don't need to have the server call out to itself to run an endpoint to check permissions. Instead, the server should just run the function.

I'm pretty sure Next does some behind the scenes black magic optimizations and doesn't actually make an API request over the wire, but it's still running through some layer of abstractions (causing it to be async) to run the function when instead it could simply be a synchronous function if implemented properly.

These abstractions make sense if you know how to use them properly, but I honestly blame Nextjs for the whole server action confusion. I remember when they first came out and seeing how almost every single question on /r/nextjs was about being confused about server actions. All these footguns and confusion to avoid some boilerplate... I'm not sure if they've improved it since, but I've moved to Svelte and haven't looked back.

I originally settled on doing this, but the problem is that you have to re-calculate everything if you ever add/remove a category. If your categories will always be static, that will work fine. But it's more than likely you'll eventually have to add another category down the line.

If your categories are dynamic, the way OP handles it will be much cheaper as the number of tweets (or customer service calls in your case) grows, as long as the cache hit rate is >0%. Each tweet will get it's own label, i.e. "joke_about_bad_technology_choices". Each of these labels gets put into a category, i.e. "tech_jokes". If you add/remove a category you would still need to re-calculate everything, however you would only need to re-calculate the labels to categories as opposed to every single tweet. Since similar tweets can share the same labels, you end up with less labels than total amount of tweets. As you reach the asymptotic ceiling, as mentioned in OPs post, your cost to re-embed labels to categories also becomes an asymptotic ceiling.

If the number of items you're categorizing is a couple thousand at most and you rarely add/remove categories, it's probably not worth the complexity. But in my case (and ops) it's worth it as the number of items grows infinitely.

Congrats on the results, that's awesome! I like the simplicity of push ups; you can do them wherever and it's very hard to come up with an excuse to not do them. Have you considered throwing pull-ups into the mix?

Personally I found it very very easy to come up with excuses to not go to the gym. Too tired, too far, it'll be too busy at this time, I don't have enough time, etc. The closest gym to me is 15 minutes. That's 30 minutes round trip + ~$260/yr + having to wait for most machines. Going 5 days a week would be 130 hours/yr in just driving for me!

I finally cancelled my membership and built a home gym. Best decision I've ever made. It costed me around ~$1200 in total for 300lb of weights, a power rack, an olympic barbell, a diy bench, and a full calisthenics "park" [1]. I've been a lot more consistent as I have zero excuses to not workout! The only thing I miss is the gym environment though; it's harder to be motivated when nobody is watching. I've found having a goal/routine to help with that though.

[1]: https://www.youtube.com/watch?v=29ESce1kqRc

> Limitations: ... Finally, while we report strong results on individual datasets, we have not yet demonstrated generalization to unseen data, an essential step toward general TSLMs.

From the paper itself...

Imagine you asked ChatGPT a question but it could only give you answers from a single blog.

> advanced pattern detection... detect new class of complex patterns

This sounds great and all, but it's wishful thinking. There isn't anything in this supporting that it's able to find any meaningful patterns beyond existing solutions (i.e. standard rules based detection/machine learning as mentioned above).

What they've essentially done is taken a dataset in which each report was "annotated with a report string (generated by cardiologist or automatic interpretation by ECG-device)" [1] and used it with a series of templates (i.e. questions to ask the llm) from the ECG-QA paper [2] to fine-tune a model to achieve 65% accuracy with solely pattern recognition and 85% accuracy with pattern+clinical context (i.e. patient history).

The 42 template questions they used (as mentioned in 4.1 in the paper) can each be evaluated deterministically via code and retrieved via a tool call for any llm to parse. And I argue that the results would be the same, if not better, for a fraction of the cost. Doing calculations like this on time series data is very very quick. A couple ms at most. I don't see why this couldn't be run on the edge.

Plus, Table 9 shows this thing takes a minimum of 7GB of ram usage with a 270m parameter model and ~15-20GB for a 1B model. I don't see how this could be run on the edge considering most phones have 6-8GB of ram.

[1]: https://physionet.org/content/ptb-xl/1.0.3/ [2]: https://arxiv.org/pdf/2306.15681

I understand this provides a way to interact with ts data via natural language, but is there any benefit to this over tool calling to a library that uses signal processing and/or rule based algos (or using machine learning if the data is noisy/variable)?

For example, you ask an off-the-shelf LLM to analyze your ECG data. The LLM uses a tool to call out to your ECG ts analysis library. The library iterates over the data and finds stats & ECG events. It returns something like "Average heart rate: 60bpm, AFib detected at <time>, etc...". The LLM has all the info it needs to give an accurate analysis at a fraction of computational cost.

On top of that, this requires a large annotated dataset and a pre-trained model. And correct me if I'm wrong, but I don't think it's possible to have a "general" model that could handle arbitrary time series data. I.e. a model that is trained on ECG data would not be compatible with stock market data. And there isn't a way to have a model that understands both stock market data and ECG data.

> daggerjs.org is parked free, courtesy of GoDaddy.com

I think your site broke? Also, I'd scoop up daggerjs.com while you're at it.

I'm curious how well this will do. Marketing websites are extremely important for first impressions (unless you're Berkshire Hathaway [1]). Although this is impressive and unique, it took me a minute to get over the "learning curve".

Reminds me of Jakob's Law, "Users spend most of their time on other sites. This means that users prefer your site to work the same way as all the other sites they already know" [2].

But given your target audience is developers, this might actually do well.

[1] https://www.berkshirehathaway.com/ [2] https://lawsofux.com/jakobs-law/

I've had it happen to me exactly once in the past few years. And a simple refresh fixed it. Definitely an overstatement to say it's common.

> And that all-nighter? It comes with a fucked up and unproductive morning the day after.

Yea I don't think I've ever pulled an all-nighter that was "worth it" outside of school. School is temporary and you're probably only pulling all-nighters your last year.

But work is different. You are working for the majority of your life. If you set your standard of life to prioritize work over your mental AND physical health, you're not going to make it past retirement (if you haven't already burnt out).

Reminds me of this [1] article. If us humans, after all these years we've been around, can't relay our thoughts exactly as we perceive them in our heads, what makes us think that we can make a model that does it better than us?

[1]: https://www.experimental-history.com/p/you-cant-reach-the-br...

Algorithmic trading is a deep rabbit hole that will drive you mad the more you try to understand it. There are just too many variables to account for and I genuinely don't understand how you could make a stable trading system that reliably makes money as a retail trader.

Excluding HFT (which is reserved for people with hundreds of millions to invest in infra, fresh Ivy league quant analysts, and a fiber optic cable hooked up directly to the exchange; they likely already have an in-house tool that does what this project does), you're really just left with intraday trading or long term investing. Investing doesn't require algorithmic trading or back testing, so it seems that this projects demographic is aimed toward intraday retail traders.

With intraday trading, your chances of making a successful trading algo are near 0%. I mean, think about it: you have to account for every single variable in the stock market. How are you supposed to account for a truth social post imposing or lifting tariffs? Or a ransomware attack crippling a company? Or if a whale decides to sell all their $BIGCORP shares on the flip of a coin? It's impossible. Your only odds of success with intraday trading is manually doing it. You yourself are an "algo" trader that is capable of changing their strategy on the fly and accounting for unknown variables. A pre-programmed algo can not, no matter how much context you give it.

Furthermore, with back testing, it's impossible to accurately capture the context of the market during that time. Let's say you back test on 180 days of data. Well, do you know exactly what happened on the 71st day of that data? Did you account for that fed meeting, that tariff hike, etc? What about all the other days? Testing on OHLCV alone is not enough; you need the entire context of the market.

While the project itself it neat, I just don't see how algorithmic trading could lead to any long term success.

Genuine question: is this an issue with auto-reload? Why not just keep a smaller amount in there at a time and let it auto-reload?

Yea I don't understand how people are "leaving it running overnight" to successfully implement features. There just seems to be a large disconnect between people who are all in on AI development and those who aren't. I have a suspicion that the former are using Python/JS and the features they are implementing are simple CRUD APIs while the latter are using more than simple systems/languages.

I think the problem is that despite feeding it all the context and having all the right MCPs agents hooked up, is that there isn't a human-in-loop. So it will just reason against itself causing these laughable stupid decisions. For simple boilerplate tasks this isn't a problem. But as soon as the scope is outside of a CRUD/boilerplate problem, the whole thing crumbles.

I would personally never touch a frontend not written with a framework. Sounds like a terrible developer experience--especially with a team. But from reading your article, it sounds like your issue is with React itself. I would recommend you try Svelte, it sounds like what you're looking for. It's as close to vanilla js as you can get with all the benefits of a framework.