arnorhs

Which EU grant did you receive? Ie. from which fund?

edit: nm, rtfm, it was on the landing page: Horizon Europe programme

The only cases where I've had gemini step on my toes like that is when a) I realized my instructions were unclear or missing something b) my assumptions/instructions were flawed about how/why something needed to be done.

what ever will i do /s

the upside this is a great opportunity to do an early bed time

interesting, so you guys call it a ratchet file? i thought it was something that OP came up with

Interesting, props for coming up with a good name.

But it's weird to me to call this a "ratchet", and not just a custom lint rule. Since it sounds exactly like a lint rule.

The hard-coded count also sounds a bit like something that I would find annoying to maintain in the long run and it might be hard to get a feeling for whether or not the needle is moving in the right direction. - esp. when the count goes down and up in a few different places so the number stays the same.. you end up in a situtation where you're not entirely sure if the count goes up or down.

A different approach to that is to have your ratchet/lint-script that detects these "bad functions" write the file location and/or count to a "ratchets" file and keep that file in version control.

In CI if the rachet has changes, you can't merge because the tree is dirty, and you'd have to run it yourself and commit it locally, and the codeowner of the rachet file would have to approve.

at least that would be a slightly nicer approach that maintaining some hard-coded opaque count.

Presumably this would work to prevent infections, but not to eradicate them once they have infected the subject.

I mostly have my scripts in package.json "scripts" section - but sometimes the scripts invoked will actually be .ts files, sometimes just bash if that makes more sense.

Though, I generally run these scripts using bun (and the corresponding `$` in bun) - basically the same thing, but I just prefer bun over deno

Yes I agree, and the replies don't really make it any more clear.

The biggest differentiator of design thinking is really addressing the XY problem. In 95% of cases clients will come to you to design their solution. Ie they already think they have a solution to their problem and now they want it to look good.

Design thinking is basically more like root cause analysis, or the 5 why's.. and an emphasis on taking to end users (the people with the problem) without having a solution.

Once you understand the problem more fundamentally is only when you start cooking up with a solution.

And the result of that process might not even be a traditional design, but perhaps just a tweak to something, like moving your onboarding to later in the ca process..

In practice however.. 95% of designers who say they practice design thinking disregard this, and just want to design wherever the client asks for

I agree with you, however your approach results in much longer LLM development runs, increased token usage and a whole lot of repetitive iterations.

+/-

> They are bad at deciding requirements by themselves.

What do you mean by requirements here? In my experience the frontier models today are pretty good at figuring out requirements, even when you don't explicitly state them.

> They are bad at original research

Sure, I don't have any experience with that, so I'll trust you on that.

> for example developing a new algorithm.

This is just not correct. I used to think so, but I was trying to come up with a pretty complicated pattern matching, multi-dimensional algorithm (I can't go into the details) - it was something that I could figure out on my own, and was half way through it, but decided to write up a description of it and feed it to gemini 2.5 pro a couple of months ago, and I was stunned.

It came up with a really clever approach and something I had previously been convinced the models weren't very good at it.

In hindsight, since they are getting so good at math in general, there's probably some overlap, but you should revisit your views on this.

--

Your 'bad at' list is missing a few things though:

- Calculations (they can come up with how to calculate or write a program to calculate from given data, but they are not good at calculating in their responses)

- Even though the frontier models are multi-modal, they are still bad at visualizing html/css - or interpreting what it would look like

- Same goes for visualizing/figuring out visual errors in graphics programming such as games programming or 3d modeling (z-index issues, orientation etc)

That's the orm argument. "If I need to switch DBs..."

In practice, that is not really viable and should not be a motivating factor when choosing technologies.

I would guess it is.

Also:

> Exploitation of this vulnerability requires an attacker to first gain authenticated access to your Redis instance.

This idea of every PR being a small chunk that you can review in 5-10 minutes is completely ridiculous. It is reasonable for bug fixes or small improvements, but the review time you should expect for a PR should reflect the size and impact of a feature, not some arbitrary number.

Yes, everybody would love it if every PR was small enough. In reality that is not a good way to build substantial features.

Often, fully building out a substantial feature, causes you to change your mind and completely changing your approach the further along you are. You don't want to be muddying up the PR pipeline with a bunch of half-assed changes.

Doing that just makes reviewers less inclined to give good feedback on a PR, because they "know it's going to change so much anyways".

If you are building a substantial feature, it is reasonable that the PR is large and reviewers will have to dedicate substantial time to reviewing it. Reviewing it is work on its own and hopefully your engineers have dedicated time to review substantial features.

Of course, you should make sure your substantial feature is as minimal as possible, for whatever is needed to ship the feaure - but not any less than that.

Yes, those have been really decent IIRC - don't remember ever having issues upgrading

First off, since the sentiment here is really negative, I'd like to say that next.js is actually really good for what it does. You've done a great job at building the software that powers millions of websites at this point.

I think a big part of the negative sentiment derives from the fact that detailed documentation and reference documentation almost non-existant. The documentation mostly tells you what exists, but not how to use them, how they get executed, common pitfalls and gotchas etc etc.

The documentation is written to be easy and friendly to newcomers, but is really missing the details and nuances of whatever execution context a given api is in and does not touch on derived complexities of using react in a server environment etc.

This is a trend across a lot of projects these days - often missing all the nuances and details - writing good documentation is really hard. Finding the balance between making things user friendly and detailed is hard.

Keep it up

Absolutely correct. Those are runtime execution context-issues. There are other frameworks that do force you do deal with those (and in other languages, probably), but I believe in next.js the difficulies are at another level - because of poor documentation and the built in abstractions to allow for running next.js both in development, node.js server, and edge.

Not at all, imo

Tbf my experience was the opposite. But sure if I'm just terrible or if it's harder on a phone, but my first tries were sub 20s and my highest was 45 before giving up xD

Meanwhile - I always just find myself arguing with every model while they ruthlessly try to gaslight me into believing whatever they are halucinating.

I have a had a bunch of positive experiences as well, but when it goes bad, it goes so horribly bad and off the rails.

Congrats on making it to V1!

Though not immediately obvious, there's a lot of parallels to be drawn between this and solid.js (proxy is a sort of `signal` right?, no virtual dom) - I'd be curious what you'd say are the primary benefits of this library over something like Solid.js?

I gotta turn a little negative here...

Off the bat, regarding the first point in the "Why use Aberdeen?" section, I have a few nit-picks:

- "Elegant and simple" - Is it though? Developers should in general be more careful about conflating simple with easy - "Elegant and easy" is probably more accurate, since having a magic proxy function, that will ensure that registered functions will be re-run etc does not constitute "simple" to me.

- "Express UIs naturally in JavaScript/TypeScript, without complex abstractions, build steps, or JSX." - I agree that having an option in the UI library space, where it is no-JSX fist can be a huge benefit in a lot of cases. Personally, these days, given how many ways you can transform and use JSX, I doubt a lot of people feel like that's a huge benefit. And in many ways, it's more natural to express DOM structures as JSX-ish components.

- "No hooks, no setState, no lifting state, no state management libraries." - this is just plain gaslighting. You may not call your API's functions "hooks" and you may very well not call your "proxy()" function a `useState` / `createStore` - but people are still using them the same way... and you end up having to solve all the same issues as with all those libraries

- "Just proxied data and automatically rerunning functions." - this is a big "just"

You are pretending that this library does away with a lot of things that are the bread and bones of other UI libraries but then your UI library still needs all those things.

I'm also curious how your proxy() handles the diamond problem in reactive state, if at all.

--

I have nothing against people building UI libraries for fun - and finding specific use cases where the libraries work well.

Eg. focusing on the lack of build can be a big benefit to a lot of projects / setups that don't perhaps have any kind of build facility etc.. also thinking about "copy pasted scripts" etc - but trying to frame it in a way that it is superior to using something like JSX seems like gaslighting to me.

On a side note, the re: typescript - you do not seem to have strict settings when developing - (from looking at the code examples) - that is already a bit of a red flag and I'd be worried I'd have a lot of TS issues when using the library.

I'll try it out when I get home, and sorry about being so negative.

This looks super neat and probably a fun project to build.

> It's a nice dream, of a synthesizer where any knob can be pulled out and replaced with a patch cable, and any jack can have a knob plugged into it to set it to a fixed value. Whether it's actually practical to build a synth like this I'm unsure. It would probably only be worthwhile if you applied it to every single control on the modular, which rules out using other people's modules. You would have to invest heavily into the Eurorack Knob Idea. You couldn't even port other modules that easily, as many of them would expect a real potentiometer, whereas the encoder can only produce a voltage. Coupling it with a voltage-controlled potentiometer would work, but would be even more expensive.

Yeah, it's hard to imagine this fitting in nicely to everything since it's defintely more effort and work than just having a knob and a jack for the control of a particular thing. Esp. since most of the time, as a convention, you'll have a knob that controls the value, but when a jack is plugged in, this same knob acts as the attenuator for the signal.

I would have appreciated having an image or a pdf of the schematic for the design to understand it properly - i can get it from your github but I don't have kicad installed on this computer.

I'm esp. interested in the normalized behavior - ie. when you have a signal plugged in to the jack that is _not_ the potentiometer.. does it get passed through or does it have to go through this chip as well?

Having to supply a 3V to this to make it work as well is also an extra requirement of its usefulness in normal eurorack circuits - not a total dealbreaker but that does add extra requirements, and extra components to one's design.

Anyways... really cool idea :)

This is correct.

The subscribers are unlikely to be garbage collected with a weak ref as long as something else is pointing to the subscriber, so it would be a viable alternative to manual unsubscriptions - but personally I prefer to give explicit lifecycle controls to the subscriber, if possible.

I'm not a huge fan of using CustomEvent for this.. esp. in terms of interoperability (which for these <kb challenges probably doesnt matter)

personally, i'll just roll with something like this which also is typed etc:

    export function createPubSub<T extends readonly any[]>() {
      const l = new Set<(...args: T) => void>()

      return {
        pub: (...args: T) => l.forEach((f) => f(...args)),
        sub: (f: (...args: T) => void) => l.add(f) && (() => l.delete(f)),
      }
    }

    // usage:
    const greetings = createPubSub<[string]>()
    const unsubscribe = greetings.sub((name) => {
      console.log('hi there', name)
    })
    greetings.pub('Dudeman')
    unsubscribe()

No it's been there for ages. Finalized as part of ecmascript 5

What you are probably thinking of is the context parameter of the reviver callback. That is relatively recent and mostly a qol improvement

Sorry to be the debby downer, but this feels completely irrelevant to HN. Why on earth is this allowed to fly? Is there some context that I'm missing?

This is not accurate. I do not know the details but netlify served things from a CDN by default if you set things up correctly with a CNAME entry in your DNS record.

People often misconfigure things by pointing their domain to netlify's IP with an A entry, but this is a user problem, not a netlify problem.

I'm sure their builds/functions run in a single region but not static files

I'm not an expert in this field, but won't you quickly exhaust most context windows with any reasonably sized repo?

I think both of the government parties have said they'd support a public vote for whatever EU deal gets proposed, so that's a possibility. "Getting ready to join": perhaps. But that would still take some time.

Nice, looks promising. How does this compare to drizzle?

Context:

We've had a lot of ORM frameworks come and go in node.js - sequelize, typeorm etc, but none of them have really caught on.

Things have been changing a lot lately after typescript took over, so we've seen a bunch of ORMs take off that give you a really good typescript experience.

So, the juggernaut in this space is of course prisma, which is super expressive and over all pretty decent - it comes with its own way to define schemas, migrations etc .. so that might not be everybody's cup of tea. (and then there's the larger runtime, that have lambda-users complaining - though that has mostly been addressed now where the binary is much smaller)

So despite it being a pretty opinionated framework really, what it gives you are really rich typescript integrated queries. And all in all it works pretty well - i've been using it at work for about 3 years and I'm just really pleased with it for the most part.

The newcomer in the space that's gaining a lot of traction is Drizzle - where it's mostly a way to define tables and queries - it also gives you really rich typed queries - and it happens all in TS/JS land.

this project of yours reminds of drizzle - kind of similar in a lot of ways.

I'm super interested to understand how this compares to drizzle and which problems with drizzle this attempts to solve

You don't (mostly, except by ear) and that's part of the allure of it.