evnix

Really like the singular and plural name approach. API is a real joy to use.

reminds of kysely typed SQL builder which was perfect to use with postgres in one of my previous projects.

I currently am working on a sqlite based project but based on Tauri's sqlite connector which is plain SQL.

Is there anyway I can make use of Flyweight in Tauri based projects?

Just curious, why would you do this instead of,

export const someDep = new Dependency();

You can export a lot more of these statements.

and use it everywhere as these act as singletons in lets say a node JS environment.

By rewriting the whole archive though

Any recommendation for a format that supports editing and deleting files without rewriting the whole archive

I would want everyone to know about the alternative, "fx"

You can do a lot more with it like map filter reduce etc and the semantics are closer to what you already know. Supports YAML too.

https://fx.wtf/getting-started

Did not know this existed even after searching for sqlite alternatives for embeddable relational databases.

I use sqlite for storing configs with data rather than dumping everything in one big YAML.

I might give duckdb a try in our next project

No. Don't want my kid to become a software coolie like us. With AI and scrum masters and micro managers, it is quickly becoming more of a replaceable blue collar job.

It is just cheaper to create an app/website in Dark Mode these days. The loud minority is placated and the rest don't care.

There are some well researched alternatives to CSV,

From the top of my head, I can highly recommend SML

https://dev.stenway.com/SML/SimpleML.html

Recommend watching the, 'stop using CSV video' too

https://youtu.be/mGUlW6YgHjE?si=zDG_9Jv8LSy-ttP4

The UI side is clamping down on features,

The browser extension requires you to pay to use TOTP and so on.

Assuming this is a tech role, You are already a decent architect, If you can design/describe your architecture without using the following terms,

Event driven, DDD, Microservices, Service bus/mesh, Web scale NoSQL, graph, vector DB.

If not, become a good developer first. IMHO, You need to be a very good developer to become a good architect. Every good architect is a good developer but not every good developer is a good architect.

We have those pointless documents used by architects at my place of work, most of them have something on the lines of,

Micro services, Kafka, Kubernetes, because what if we have a billion users compared to the current 4k users.

GraphDB, what if SQL would not be enough

ElasticSearch, what if we have to do full text search along with stats.

But most of these documents are just short for any of these, "I want to try this new architecture/technology because it's fun, my colleague at a FAANG uses it, I've read the BOOK, and it looks good on my CV".

When they jump to design the next Big project, we have to deal with their decision, having twice as many services than our team, having to keep all the above mentioned DBs and technologies in sync which is of course a simpler problem than making those "big architecture decisions".

Sorry for the rant :(

Have to agree on this one. As a current user of Hono, I'll just switch to a proper router.

I don't want those SSR oddities and react like "hooks" sneak into our backend codebase. They have been a constant source of confusion, bugs and performance issues in our frontend app.

Let me save you from typing the obligatory HN response: YoU DoNt HaVe tO UsE ThOsE

The code that we currently write is at a sufficiently high level that we don't need to reach for a debugger.

I have a local kubernetes cluster with 10 services running, I usually get to the root of the problem a lot faster with a few log lines than having to figure out how to configure my IDE, run the app in debug mode and get all the debug port mappings right and have the right source mappings configured. If the problem is less around business logic and more around algorithms, that's when I spend time configuring everything and stepping through the debugger.

I start using fish, really like its feature set, but then have to give up and switch back to zsh when I want to get anything done. Unlike zsh, Fish isn't compatible with bash syntax, so a lot of existing scripts and software just doesn't work right. Even today people write scripts as if bash already exists and they seem to always target it. I wish fish had some form of compatibility layer.

Why would it result in stale data being returned most of the time?

The other way to look at it is that the modern way of calculating is essentially the ancient Indian way of calculating.

I am glad I don't have to do modern physics and mathematics using the Roman numerals.

If you are looking for a light weight intelliJ alternative, then this is it.

I understand the whole CommonJS Vs imports situation.

I have been that vocal minority that keeps complaining about CommonJS support to library authors. But I have given it up for the greater good.

we have a standard now, CommonJS needs to go, why keep pushing non standard stuff in a 2023 article.

Did this recently, on a largish project based on express and typeorm. The only issue we had was with a native image manipulation library in combination with alpine linux image which was an easy fix. Rest worked flawlessly. Performance wasn't an issue for us, Dev experience was really bad on Node and the amount of hacks required to get esm/commonjs working in tandem was insane. Bun got rid of a lot of those hacks and we are slowly cleaning up the codebase.

If we give up a bit of our snobbery on what is Computer Science, we may realize this is probably a sane starting point for a lot of students. The generation today hasn't grown up with computers like we did, most only had a cellphone which hides away even basic things like the filesystem and goes to the extreme extents to stop you from tinkering with it.

You need a foundation for you to start making sense and to connect the dots for even the basic assumptions and theories that you may come up with.

Another way to put it is you need to know numbers(or atleast a basic sense of what they are) before you do math.

Not nestJS, but built around express typeorm and the rest and the code base is 5 years old so you can imagine.

Bun has seriously been a god send. I am so happy that we can finally do top level awaits and it allowed us to delete a lot of hacky code that we had in place just to make node and all the build dependencies happy.

Do we have something like this but for rust?

The problem is the difference in pricing between the 16 and the 32gigb one, the manufacturers are taking advantage of the sodering which is almost going to be the default in the upcoming days, and taking consumers for a ride.

I did my part, my website shows "Not available on Chrome, Use a more modern and open browser instead... and some explainer text"

if most of us Devs do this, this change would have no chance.

What would be even nicer is If someone can build a JS file that the rest of us could include to show a hard blocking pop up just to show how the future web might look like, supported with a nice explanation and link to good videos, that would be nice too.

We have had pretty bad experience with NATS. Apart from core NATS which is just in memory, you need their sub modules to build any kind of serious business on top of it.

We initially built our code around NATSStreaming, they then went ahead and deprecated that.

But since we saw so many big companies using NATS, they thought it might be a good idea to stick with it and we did a year long migration to their shiny new NATSJetstream Push based approach, but from what I see now in the conversations they are going to deprecate that too in favour of Pull based approach which is architecturally very different, now we will have to somehow convince management for another rewrite. I am not sure if we should even rewrite or just move to another product at this point.

Dear NATS, please stop throwing away and rewriting protocols and products. Or make it such that the end client libraries would handle that upgrade automatically with a library upgrade.

We should have just stuck with the more traditional Kafka or RabbitMQ.

What I have also learnt is that when companies put big brand logos on their websites, it just means some random Dev from that company is using it for their side project or experimental mini project.

We all know how this will be used in the next firing round.

I've done a lot of contracting jobs and I get to see a lot of codebases and had the exact opposite experience, Whenever I see react or vue code, and in particular react, I feel like I have to relearn everything because the combination of external state libraries and to top it with translation specific code and libraries makes it such that each code base is very different from the other. It almost feels like you are learning a new framework altogether. The other issue is not directly related but because there are so many external dependencies, there is this constant slog work to keep everything updated due to constant vulnerabilities that keep popping in our CI tool.

Familiarity wise Angular has been probably the easiest to jump into and maintain long term, but it is a pain to work with due to the amount of ceremony involved to do even the simplest of things.

Svelte codebases due to the very nature of Svelte are simpler and very straightforward to get into, there are some svelte specific things but they aren't too many of them and are simpler to reason about when compared to codebases built on hooks, and even worse are hooks in combination with junior Devs. It is very very easy to write bad react code and you see this way way too often. Most react code out in the wild is badly written, you don't see problems because the browsers and modern computers are performant enough to hide them away but you do notice as the codebase grows and you realize it too late that the very foundation was wrong.

I don't mind Vue and just see svelte as a nicer DSL over it.

Please go through his YouTube videos, he records a good portion of his work.

I personally learnt a lot more from his videos than from any book.

Here is my second attempt with interpreters, It is a 7 part series. it uses JSON as AST and mostly goes into what happens after parsing and things like how scope, variables and functions can be represented.

It isn't perfect and it might not contain all the best practices out there, consider it notes from a student struggling to learn about the topic

https://returnzero.win/2023/01/28/lisp-my-second-attempt-at-...