aastronaut

https://archive.org/details/bbc-connections-1978

Fixed a bug on how the browser wasn't closing TCP connections/Motion JPEG video streams properly in a responsive behavior. Took me about 3+ hours reading through various specs and that resulted to around 20 LOC changed. I then wrote a blog post about it[0], which took me about 10 days.

[0] https://blog.whilenot.dev/posts/cool-bugs-vs-shitty-bugs-par...

There was one in an article on hackaday[0], also featured here[1].

[0] https://hackaday.com/2023/08/16/new-motherboard-improves-old...

[1] https://news.ycombinator.com/item?id=37174147

I think it should be "The art of buying single-board computers and never running them once". I think the "once" is needed in the case of computers. They are as machines not directly comparable to books...

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...

If you had a list of all the genomes of all the people in the world, and all their phenotypes (height, eye color, hair type, etc), you could take all their genomes as input variables and treat all their phenotypes as output variables, and make embeddings or other models that mapped from genomes to phenotypes. The result would be a predictive model that could take a human genome, and spit out a prediction of what that person looks like and other details around them (up to the limits of heritability).

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.

I'm honestly a bit confused by this statement, as "React env variables" can mean various things, depending on your setup.

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...

Correction: you cannot get fired ("Entlassung") without any reason in Austria, you need rather strong reasons to fire somebody[0], but your employment contract can be terminated with a notice period anytime* ("Kündigung")[1]. The notice period is 6 weeks at minimum by law (6-12 weeks is common in startups by employment contract) and includes "Postensuchtage"[2], which allow you to use 20% of your time during the notice period however you want.

*: 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...

Had those in heavy use during my work on a surface grinder[0], I can remember it had an ancient digital interface with 0.0001mm precision. We used the blocks to calibrate our measuring table[1] constantly. Later in life I got to see the machines to measure the quality of photomasks[2] in the production line of modern CPUs, and I was just blown away when I heard about those tolerances.

[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...

https://blog.whilenot.dev

I should write more.

Maybe a link to the project would be better: https://github.com/sansyrox/robyn

[...], written in TypeScript and accelerated with C++ bindings to BLAS and LAPACK

C++ addons for Node.js are not part of the JavaScript runtime.

The level of noise is the predominant parameter in my selection for a living place. I always consult the noise map[0] before moving anywhere in Vienna/AT. I hope other governments offer the same information.

[0] https://maps.laerminfo.at/

my gut is screaming no

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.

To add to this, for me personally the difficult part in automated test isn't the definition of expected output, but the retrieval of actual output in an automated way. Test frameworks can and will only focus on a limited set of interaction (Playwright for DOM, detox for mobile etc.).

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

just patch inputs and outputs to audacity (or your recording software of choice). for pipewire theres helvum[0] or qpwgraph[1]. for JACK there's Catia[2].

[0] https://gitlab.freedesktop.org/pipewire/helvum

[1] https://gitlab.freedesktop.org/rncbc/qpwgraph

[2] https://kx.studio/Applications:Catia

i think

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]

[0] https://en.wikipedia.org/wiki/Linguistic_relativity

"now you have two problems"

Interesting take. I always look at it like "now you have a better solution for your modeling needs".

You're question seems more on the side of "Why use a micro framework when you can use a mature full-fledged one?". I feel a lot if new ideas in the web development space are first available as "micro" packages, so that's just what you use when you want to stay on the edge. I feel there is still so much momentum in the JS/TS community. Would you genuinely pick PHP for anything else besides Laravel?

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.

Maybe I understand it wrong, but I can't agree with this analogy as is...

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.

As much as I like some historical reference like the next person, I think this discussion here takes a wrong turn through comments like these, sarcastic or not. I think OP is free to criticize the process of registering a company, but should rather give suggestions to improve said process instead of ranting about the official language of a nation.

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.

Can you give some specifics about what that means in your case?

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.

there goes my evening, that's what I like about HN. thanks for the refs!

I didn't lay out a bait =)

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.

the reply button wasn't there and I assumed the reach of a depth limit... guess I just needed to wait a bit ¯\_(ツ)_/¯

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.

@lolinder

...you just removed the default case and just introduced undefined as return value at runtime, so it isn't the same functionality.

Thanks for the example! I guess we consider switch/case in different situations then. I usually make use of switches in simple mappings and switch/case seems more readable and idiomatic to me there:

  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}"`);
    }))();
  }

Thanks for the example!

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?

Additional to what has been posted already, the shape of the lines (which ultimately will result in transistors) is defined by manufactured patterns on quartz glass photomasks[1]. AFAIK a modern processor design has a stack of around 40-60 masks placed in sequence for the light to pass through. Producing these photomasks follows a similar manufacturing process from a lithography POV, except that electron-beams[2] are used instead of a light source. The mask manufacturing process requires its own specialized machines and Intel owns companies that produce those, eg. IMS Nanofabrication[3].

[1] https://en.wikichip.org/wiki/mask

[2] https://en.wikipedia.org/wiki/Electron-beam_lithography

[3] https://www.ims.co.at/en/

GP isn't talking about meetings, where some dedicated time and space is spent to discuss a certain topic.

I have two policies for casual work-related discussions:

- discussions should have outcomes

- it shouldn't exclude anyone (not the same as: it should include anyone!)

...and a simple policy for non-work related discussions:

- feel free to chat about private topics however and to whomever you prefer

So:

- try to schedule meetings for important things and make anyone that could/wants to learn from it feel included

- if it's just casually pondering about architectural things and there is an outcome, you are obliged to provide a non-exlusive summary to the other team members (and should be able to give a reason on why this discussion was taking place exclusive to others like it did)

- and, if there isn't an outcome, the discussion wasn't worth its time and there shouldn't be a need to involve anybody else

Location: Vienna, Austria

Remote: Yes

Willing to relocate: No

Technologies: React, TypeScript, Go, C, Rust, Deno, Next.js, Haskell, OCaml, Elixir, Bash, PostgreSQL, Ansible, Terraform, Linux

Résumé/CV: email me please

Email: hnwwtbh@whilenot.dev