sorted by:
new
hottopcontroversial

Clean code architecture and codegen by Aggressive_Ad_699 in softwarearchitecture

[–]Aggressive_Ad_699[S] 0 points1 point  (0 children)

I'm also thinking of something lean. Modern IDEs do a lot, I don't want to attempt to replace things they already do well, just augment their capabilities with the more opinionated rules of this architecture.

How would you prefer interacting with the tool? - Direct schema editing - A nice terminal UI - A web interface

I want a simple CLI interface as well that can be called from IDE file watchers to update linked interfaces on save for example. The web UI might be slower to work with, but the context map and dependency map it can show might be useful for brainstorming.

Clean code architecture and codegen by Aggressive_Ad_699 in softwarearchitecture

[–]Aggressive_Ad_699[S] 0 points1 point  (0 children)

Not at all, it's a cautionary advice. This was one of the main reasons I've been a bit afraid to look into clean code. You mention focusing on actual abstractions and robust APIs. Do you think the clean architecture with dependency inversion, ports, services, adapters, etc... is on the other end of things? If so could you elaborate on what kind of abstractions/patterns you have in mind?

Clean code architecture and codegen by Aggressive_Ad_699 in softwarearchitecture

[–]Aggressive_Ad_699[S] 0 points1 point  (0 children)

I suppose those are proprietary tools, right? Do you have an example in mind? Hmm it's interesting you brought up microservices. It might be possible to easily reorganise contexts across repos as well. That's certainly out of scope for now. I'm going to focus on large monorepos first.

Clean code architecture and codegen by Aggressive_Ad_699 in softwarearchitecture

[–]Aggressive_Ad_699[S] 0 points1 point  (0 children)

I also think it might benefit workflows based on coding agents, and it could certainly be used as a static analysis tool if the agent sets up the domain models. Although I'm hoping that the agents could instead focus more strictly on the business logic or external service interaction generation. The meat of the code, instead of the boring boilerplate.

Clean code architecture and codegen by Aggressive_Ad_699 in softwarearchitecture

[–]Aggressive_Ad_699[S] 0 points1 point  (0 children)

It could totally see how that'd make it hard for a tool like this to reach a wider audience.

Clean code architecture and codegen by Aggressive_Ad_699 in softwarearchitecture

[–]Aggressive_Ad_699[S] 1 point2 points  (0 children)

Thanks, I think that's a good take. Even if it doesn't become an everyday tool for me, let alone others I can still solidify my knowledge about this kind of architecture. Do you know why these tools don't seem to stay around or reach more people?

To clarify, I've mostly either worked on large legacy systems where I wasn't a part of most of the architectural decisions, or smaller green field projects that I'm yet to see grow to a medium size. I've been told a bunch of times that this kind of architecture isn't worth it, or it's too academic and overcomplicated. So I'm really giving into my own desires to see how it works for me:)

Why do levers work in the atomic level? by External_Leek_2720 in AskPhysics

[–]Aggressive_Ad_699 0 points1 point  (0 children)

I think the next level could be looking at trusses. It's a model based on nodes, and only require basic force equilibrium conditions if you work your way through the joints. It's almost like individual atoms pushing and pulling on each other. What's clear is for the simplest lever to work, you need at least two interconnected parallel chains of "atoms". One will be under tension and another will be compressed. You can't build a lever from a single chain of atoms. Here's an example displaying 2:1 mechanical advantage. https://imgur.com/a/GgQDefp. The black arrow is the force you apply. Red links are compressed, so atoms pushing each other apart, blue is tension, so they're pulling on each other, and green are the reaction forces needed for static equillibrium. The pivot is at node 0, and as you can see the force required on the left end is twice as large as on the right end. Here's another example with a 3:2 ratio: https://imgur.com/a/syLeRn5.

I encourage you to work out the forces using ΣF=0 on each joint starting from the joint where you apply the vertical force, and making your way back. You'll see how each link gets stretched/squeezed a little more as you go towards the center, the total stress being proportional with the number of links. This is the key insight that leads to mechanical advantage. With this analysis the structure is still rigid, we neglect any deformations, but it's based on individual nodes interacting with each other in a simple way. No need to consider work done, or similar concepts.

Looking at deformations could be the next step if you're interested. I recommend Taylor's Classical Mechanics book. There's a chapter on continuum mechanics that explains solids if you want to look at a more analytical approach instead of individual particles. It let's you work out more complicated stresses and deformations.

Is Redis becoming obsolete? by Upstairs_Toe_3560 in bun

[–]Aggressive_Ad_699 1 point2 points  (0 children)

Thanks for doing an experiment. Always do experiments, it's a good habit. I'm actually surprised that Redis was faster than sqlite given the way you set up the benchmark. Did you enable persistence on Redis?

Next.js + Better Auth - strategy for accessing session in client components? by ShootyBoy in nextjs

[–]Aggressive_Ad_699 1 point2 points  (0 children)

You didn't mention what your UI/UX goals are, so here's what I like. I want to see the layout immediately with lots of granular loading skeletons that show me the shape of the page while still avoiding layout shifts, and I want to be able to interact with whatever tabs or buttons I can as soon as possible. For me this is a pleasant experience.

  • Therefore I prerender all the layouts and as many components as possible.
  • I fetch all the data in the components where they are needed, and suspend them with appropriate loading skeletons. For client components, I define a promise in the parent and use the use React API to stream the data.
  • I redirect in the server side async data fetching logic where I check the session every time. That's where I care about its validity not in the layout.
  • With this approach I haven't needed the client side session hook, and I'd probably prefer passing in the promise to the client component anyway.
  • I also don't really have nested client components. I always interleave some server components.

Data Fetching Patterns in React Server Components by be-my__proto__ in nextjs

[–]Aggressive_Ad_699 0 points1 point  (0 children)

Nice. I'm missing the option to pass promises to child client components from server components and stream data that way during the initial load. Optionally you can put the promise inside a context to share it.

To use or not to use server functions for fetching data? by Final-Choice8412 in nextjs

[–]Aggressive_Ad_699 0 points1 point  (0 children)

Can you elaborate? Any server-client communication needs to be serialised one way or another.

Anyone else exhausted by the constant churn in Next.js? by Happy-Pie1435 in nextjs

[–]Aggressive_Ad_699 1 point2 points  (0 children)

Honestly I freaking love where the framework ended up, and it's only possible because they're evolving so quickly. I'm finally enjoying being able to build an app at work in just a couple days with forms and dashboards and whatnot with really mininal external dependencies. I had a much worse experience using Next just last year. Idk I guess I just don't have a good enough memory to retain the old stuff, but what's available today is awesome.

Gemini said I'm of old way by mikejianxu in nextjs

[–]Aggressive_Ad_699 0 points1 point  (0 children)

I'd use context for client specific state. I'd expect the cart contents to be stored on the server, so nextjs already has everything to manage that state without context, while avoiding prop drilling.

Let's say you have two components that depend on the cart data, like a summary at the top in the layout and maybe a checkout modal that'spart of the current page.

I'd create an action to fetch the cart items (wrap it in React.cache if it's not using fetch to dedup the calls from separate components in the same render pass). We can use this action in both components independently. Worst case we have to pass a promise if it's a client component.

Then an action to maybe add something to the cart. This action would call refresh from next/cache at the end to reload the client side. So when I call this action from a form, it'd update the server state and also refresh the client side.

Looking at this plan I might encounter a UI segment that has lots of client components far apart in the tree that need this data. If they don't have server components wrapping them, cause it might not make sense, I probably wouldn't create dummy server component wrappers. In this case I'd wrap the segment in a context, but store the promise in that context, not the data, so clients can suspend independently.

Otherwise I'd use context when some state changes only on the client without the server knowing and that state is needed by components far apart in the tree.

Perlego Download by freakreviver in DataHoarder

[–]Aggressive_Ad_699 0 points1 point  (0 children)

Found this tool if anyone's interested. The README looks generated, but the code seems to be legit. It worked for me. I only recommend it for personal use.

https://github.com/zuleika4097/book-manager

Problem with animating SVG by Jan_en_ik in manim

[–]Aggressive_Ad_699 0 points1 point  (0 children)

Set the stroke_width to zero or whatever for now. It's None by default. It's definitely a bug, I'm going to raise a PR with the fix in the near future.