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