vhakulinen

Hi HN! I’m Ville, CTO of Nuanic, a Finnish company developing a smart ring that tracks stress using Electrodermal Activity (EDA) rather than the more common Heart Rate Variability (HRV). EDA provides a direct measurement of the body’s stress response, making it particularly effective for detecting and managing chronic stress.

EDA has been an underutilized metric in wearables, largely because interpreting the raw signal is challenging - it’s messy and difficult to make sense of. To address this, we’ve developed our own algorithm that transforms the EDA data into an easy-to-understand number from 1 to 100, which we call DNE (Double Normalized EDA). On this scale, 1 represents low stress and 100 represents high stress, making it simple to track stress levels, identify trends, and take action to recover when needed.

The ring measures 24/7, providing real-time feedback around the clock, and all of this is done without any cloud requirement. Continuous monitoring lets you see how your stress and recovery fluctuate throughout the day and night, helping you make informed decisions to improve your well-being - whether that’s adjusting your workload, taking breaks, or prioritizing rest.

Research has shown a strong connection between EDA and burnout, and the ring has been designed to help with burnout detection and prevention. If you’re interested in the details, you can check out our preprint here: https://doi.org/10.2139/ssrn.4726455.

This isn’t just theoretical - I’ve experienced burnout in the past, and this technology has been invaluable in helping me avoid it since. It helps me ensure I get enough recovery, which is the key to managing stress effectively. Being able to track my recovery has made a huge difference in maintaining balance and preventing burnout from happening again.

The ring is also being used in long COVID recovery studies, where its ability to monitor stress and recovery continuously is being made use of. While the results haven’t been published yet, the ongoing research highlights the potential of the ring in supporting recovery from complex, long-term conditions.

Would love to hear your thoughts or answer any questions about it!

My last experiment was with bulma css and vanilla javascript (typescript) with web components for components that needed custom/complex interactions. Nice thing with this approach is that you can "just" render the web components with the backend's template engine as if those were your normal html tags. Because of typescript, a build step was required. For this I used esbuild (esbuild itself didn't do the type checking so I ran tsc with --noEmit and --watch next to it).

Didn't get that far with that project to see how it works when the code base scales. I would probably pick the same setup for my next greenfield project.

Rather, copied over from other languages.

Regarding the error handling case, I've played around with the idea of implementing a Result type with typescript and hiding the errors behind that. The end result looks something like this

    const res = await getJSON('/thingy');

    if (isErr(res)) {
      // Handle error.
      return;
    }

You can read the details from here: https://thingsthatkeepmeupatnight.dev/posts/simple-typescrip...

Oh, thats why the colors change. It actually hurts my eyes when jumping from link to link. So far, the purple is the worst (makes it hard to read).

From the linked post:

> Know when to break the rules.

Oni was/is build completely on top of neovim and oni2 turned vim (not neovim) into a library and builds on top of that.

I suppose the vscode plugin support is implemented in similar fashion as coc[1] does it.

1: https://github.com/neoclide/coc.nvim

You could try to calculate some numbers on savings or "wasted hours because the corporate support is slow and wont fix our problems fast enough" to turn their heads around. Another pointer could be that the students could be involved in running some of the systems.

Usually, in situations like yours, turning complaints or proposed solutions into numbers helps a lot.

> worst lang

What makes it bad?

> worst toolkit

Its actually quite decent.

> worst platform support

How come? GTK works on window, mac, linux (+ BSDs and probably other unix like systems). What else would you be looking for from this kind of software? The platform support is better than win32 and what ever the macos equivalent is.

> Why does the rust documentation still suck?

Thats a bit harsh. Yes, the documentation might be (is) a bit hard to read in a sense that its hard to _find_ something from it, but otherwise I've found if quite complete (when it comes to the standard library). Most (if not all) of your points are about the readability of the rendered documentation and not the documentation (content) it self.

Is that somehow fundamentally different from "git describe --tags --always"?

Thats just one data point, and for which you could argue that javascript has not one, but two null values: null and undefined.

PHP got (or is getting?) type hinting, while javascript doesn't have such thing (typescript or flow doesn't count). Javascript is event loop based, while PHP is (afaik) request->response based. These days, javascript usually is compiled for web, while PHP just sits there on the server and you can swap out the source files when you upgrade. You could go on and on.

Your comparison of today's js/node to PHP from 20 years ago is interesting.

I wonder if javascript will be in similar place in 10-20 years that PHP is today (e.g. "its not like it used to be and things a actually quite good now")? The language it self (javascript) might be there already, but is the community anywhere close yet? SQL injections used to be the thing PHP was known for in the past but not so much these days (the community is more experienced?). Meanwhile, problems with NPM and the whole packaging situation is what javascript is known for these days, but will the be so on 20 years?

> I think the introduction of emoji reactions was a bad idea, it gamifies the issues system.

It depends on the community. I've seen many where the reactions are genuine and actually serves a purpose. From what I've seen, its almost always a popular js/node project that attracts this kind if behaviour like seen in this thread (based on my own observations).

Last example is vscode's santa hat[1]. It seems that that thread is mostly empty now but I remember there was huge meme thread going on in that issue or in reddit/hn when that thing was happening.

1: https://github.com/microsoft/vscode/issues/87268

More and more places are "offering to give a tip" at least in Helsinki when paying by card. The machine asks if you want to give some or not.

Its... weird.

Besides just writing and designing software:

Developed and upheld a process for writing requirement documents for software development with my team mate.

Started to do scrum master'ish role.

Wrote a tool to manage our (really custom) development environment.

> My JavaScript tests catch typoed property names every time.

My typescript compiler catches typoed property names every time.

> I can't remember the last time I merged code with a typo in a property name.

I can't remember the last time my newly written code made it into the runtime/browser with a typo in a property name.

> ...if you typoed a property name and your tests didn't catch it, it means that either your tests are poorly written or your object didn't need that property to begin with.

The types are much more than just property names.

> TypeScript is less readable.

What makes you say so? I find it more readable than javascript.

Would be worth mentioning that the inline-webassembly npm package is created by the author and quite recently.

I guess I'm buying VR gear then.

> We just upgraded from 2015 to 2017 at our studio, which required a decently large refactor of some core utilities.

Were these utilities custom tools built for the IDE or the actual application code you were/are developing?

> What it gains in simplicity it looses in expressiveness. This leads to more lines of code per feature, and bugs in software has been shown to be a function of LoCs

If the lack of expressiveness equals to greater amount of code and thus more bugs (in Go), does the same apply for languages that are more verbose (say, Java)? And if language is more expressive and less verbose (say, Python or Javascript maybe?), does it mean less bugs?

I have the opposite: I know Rust, but I hardly know C++ beyond C (granted that I probably could figure out the not-so-easy c++ easier than I would figure out the rust version if I didn't know either). Don't get me wrong, I know what you mean. But the same can happen with many other languages too.

Is the react hook code so complicated that when it totals up to 17 lines of code[1], it needs to become a npm package? The code it self looks neat and clean - even more reason to just write your own hook.

1: https://github.com/akash-joshi/local-storage-hook/blob/7d593...

Gvim is GUI for vim (afaik its part of vim's code base). Gnvim is GUI for neovim, and is its own project.