aastronaut
[0]: https://blog.whilenot.dev/posts/cool-bugs-vs-shitty-bugs-par...
[0]: https://hackaday.com/2023/08/16/new-motherboard-improves-old...
A book, like any media, fulfilled its initial purpose after it has been "consumed" - anything else (looks nice, feels nice, smells nice) are physical, subjective qualities attached to it. You might even buy it solely for these physical qualities, but that's besides the point.
A machine has its purpose in its usage, and that usage requires known resources that should not be carelessly wasted. I personally buy them to enable a utility for myself and have fun discovering it. It fulfilled its initial purpose even if it was powered on just once.
Even those single-board computers that were put to "good use", as building blocks for new devices (eg. [0]), are still not in use the whole time.
[0]: https://www.creativeapplications.net/objects/paragraphica-co...
Would such a predictive model really be possible? As far as I'm aware there is contradicting research whether a specific phenotype distinctly originates from a SNP/genotype.
Backend and frontend can be separate runtimes... The backend could be an API-only-server and an OS process with all permissions that come with it (reading env vars during execution as it pleases). The frontend, eg. a React SPA, could just be a bunch of built HTML/CSS/JS-files (type-checked, bundled, minified, etc.), served through a static file server (separate backend, nginx?) and interpreted through a browser engine on the client.
Are you asking for nginx to parse the served HTML/CSS/JS-files and replace unknown placeholders with env var values? If so you are prob asking for a SSR framework[0], meaning a backend that treats a React project similar to template files, and is able to inject env vars?
[0]: Next.js - https://nextjs.org/docs/app/building-your-application/config...
The actual reason is a different one IMHO. The implementation of web standards enabled cross-platform engines that provide every UI customization one could possibly need for a SaaS product. This decision included many benefits for businesses and developers alike, such as:
- User data stays in the walled garden
- Users most probably already have a web-browser installed
- Responsibility to keep the runtime (web-browser) up-to-date is on the user side
- Automated updates (POV user)
- No installation instructions
I think it as much as a business decision as it was the decision from developers to bet on HTML/CSS/JS instead of GTK, QT, etc.
*: every 1st or 15th of the month is common
[0]: https://www.usp.gv.at/en/mitarbeiter/beendigung-arbeitsverha...
[1]: https://www.usp.gv.at/en/mitarbeiter/beendigung-arbeitsverha...
[2]: https://www.wko.at/service/arbeitsrecht-sozialrecht/Anspruch...
[0]: https://en.wikipedia.org/wiki/Surface_grinding
[1]: https://www.bafasan.com/en/images/kke/kke2.png
[2]: https://www.zeiss.com/semiconductor-manufacturing-technology...
I should write more.
C++ addons for Node.js are not part of the JavaScript runtime.
seems like you already made up your mind, so why bother?
TypeScript is helpful (or at least meant to be) for teams as it aims to block the cleverness of its individual contributors. Especially people only familiar with dynamic type systems are rather fighting a static type checker at first and "it's not helping them". A "strong" type checker should enforce everyone to write stuff in a simpler form and that gets in the way of productivity for some people.
If you can maintain your mindset and write your code in a simple form that could easily satisfy a type checker (coming from rust), then why bother with additional tooling if it won't provide more value to you? Or to phrase it differently: if you can maintain a strong mindset with confidence, bringing in additional tooling for that project later on, when it will be become plausible, won't be that hard. But if you doubt your mindset, it might be a helpful choice to let a type checker look over your shoulder from the beginning.
I think Brendan Gregg's books[0][1] are quite inspiring for an understanding of a system with its inner workings, and provide information about various tools one can use to dissect a system and get some actual output in an automated way.
[0]: https://www.brendangregg.com/systems-performance-2nd-edition...
[1]: https://www.brendangregg.com/bpf-performance-tools-book.html
[0]: https://gitlab.freedesktop.org/pipewire/helvum
> language enables intelligence
was just a poor choice of words here. i understood GP as "the structure of a language influences its speakers' worldview or cognition, and thus people's perceptions are relative to their spoken language"[0]
Interesting take. I always look at it like "now you have a better solution for your modeling needs".
I would also question you're mentioned frequency to update packages tbh. Just pin a stable version with a lock file, track the required node engine and use an OCI image to provide just enough reproducibility. I never had to do anything more than cd-ing into a directory and run npm ci after coming back to a project for a few years now.
An organized home means to do things right away. If the laundry is done and dried, then I'll put them away (organize them) immediately. I don't wait for other things (eg. the dishwasher) that need to be tidied up. If I service my bicycle in one room and leave a mess, then I'll clean it up right away and don't necessarily include other rooms in that cleaning cycle. But on the other hand, if I spot some dust in one room, I'll just grab the hover and go through the whole flat.
Actions can be separate, and so can scope and effort.
I feel a house is best managed when effort and scope are low, so it is in my best interest to keep it that way. If my task becomes the action to tidy my home, then I know something went wrong.
People are different, aren't they? On one side I have a friend living in Austria for about a decade now and he still complains that quite some information isn't available in English. He doesn't even see the irony as an Italian, makes no attempt to learn the official language (German) and continuously makes fun of any explanation I'm trying to give on why a specific German term would be used in a certain context. On the other hand there are people like me, who moved to Norway for about a year and frequently felt like shit that I didn't make a proper attempt to learn its official language (started a course there next to my study, but didn't finish it). I was amazed that every Norwegian I encountered was able to speak English on a very high level. Me not learning the official language, but still trying to achieve some kind of future there, really made me feel foreign and my failed attempt to learn that nations official language remained a lasting feeling of lost time. I would never consider to complain that some documents aren't available in English.
react-query has a default behavior to cancel a fetch when the component unmounts (AFAIK), eg. the user changes to another view and the data of the previous view aren't needed anymore. I prefer to only have those fetches pending which are actually needed and seem likely to succeed, as otherwise my SPAs would just add unnecessary load on the API gateway. I specifically had such a case when the backend team was in transition to a microservice architecture, hence the timeouts.
But thanks, will join the discord then after I created a repo to play around.
It would also look more readable to me with a default return value. An exhaustiveness check just keeps your mapping functionally pure and the type checker can catch it.
Moving the case for a default value to the caller is a weird choice IMHO. Types should reflect the assumed state about a program, but we all know the runtime can behave in unexpected ways. Assume an SPA and the response of an API call was typed with CountryCode in some field, then somebody just worked on the API - I prefer to crash my world close to were my assumption doesn't fit anymore, but YMMW.
Your implementation (and safety from the type checker) only helps at build time and puts more responsibility and care on the caller. That implementation could prolong the error throwing until undefined reaches the database, mine could already crash at the client. Either TS or JS will do that.
...you just removed the default case and just introduced undefined as return value at runtime, so it isn't the same functionality.
type CountryCode =
| "CH"
| "US";
function nameFromCountryCode(countryCode: CountryCode): string {
switch (countryCode) {
case "CH": return "Switzerland";
case "US": return "United States of America";
default: // exhaustiveness checking
((val: never): never => {
throw new Error(`Cannot resolve name for countryCode: "${val}"`);
})(countryCode);
}
}
type CountryCode =
| "CH"
| "US";
function nameFromCountryCode(countryCode: CountryCode): string {
return ({
'CH': (() => 'Switzerland'),
'US': (() => 'United States of America'),
}[countryCode] || (() => {
throw new Error(`Cannot resolve name for countryCode: "${countryCode}"`);
}))();
}I assume the identical performance just comes from the optimization of the JIT, as allocating objects in the heap seems quite overkill for such a control flow. I only fall back to this when switch/case isn't available in the language, eg. in Python.
Is this a thing in the JS community?
Recently I had a look at the kubeshop-dashboard repo[1] and their use of the RTK Query API[2]. When I write the boilerplate for any SPA nowadays, I usually like to merge any fetching logic with the lib-specific notification/toast-methods, in order to render something to the user about any reached warning- or error-timeouts for each ongoing fetch by default. Meaning:
- every new fetch would start a timer
- after 10secs a warning-notification is shown "a fetch takes longer than expected..."
- and after 30secs the AbortController signals the cancelling of the ongoing fetch and an error-notification is shown "fetch took to long. click to try again."
The implementation of react-query, its "hook-yfied" nature, makes it super easy to wrap it and merge it with the component-lib to create such a thing. I just need to wrap its provided hooks (useQuery, useMutation) with "hook-creators" (I usually call them createQueryHook and createMutationHook) and don't need to dive into any of its implementation specific details. But createApi, as provided by RTK Query API, makes this quite a bit harder, or so it seems to me at least. How would you wrap createApi to provide such a functionality for every fetch by default?
[1]: https://github.com/kubeshop/testkube-dashboard
[2]: https://github.com/kubeshop/testkube-dashboard/tree/main/src...