This is how AI can be configured for product discovery: https://stand.chat/guide/product-discovery
Not a substitute for human-to-human, but still collects insights.
HN user
This is how AI can be configured for product discovery: https://stand.chat/guide/product-discovery
Not a substitute for human-to-human, but still collects insights.
When resizing, I expect to drag from the edge of a window. This is exactly how it works in macOS Tahoe, with a sufficient drag zone on the both sides. The only "strangeness" is that the drag zone extends further outside the window in the corner zone. IMO this is nice.
All that said, I REALLY would love to have a hotkey combo I can beep pressed down to resize anywhere over the window. Just like in many Unix/Linux window managers.
After 25 years of building web frameworks at Vaadin, we asked: what if the AI is in the driver’s seat? Would we even need a UI?
In Computer–Human Interaction (CHI), the AI runs a business process. When it needs something from a human, it creates a purpose-built UI in real time, adapting as you interact.
No code. No pre-built app. Just AI “speaking” in UI.
Demo: computerhumaninteraction.com
Questions for HN: • Best use cases you can think of? • Which AI models would work best for this? (everything we’ve tried so far is either too slow or too dumb) • If CHI creates something innovative, please share the link to prompt here (you can copy it from the demo after it yields results)
Vaadin’s 3rd brand iteration is a refinement embracing touch of geekiness. Toolkit is for internal use, but shared publicly as it might help others building dev-led products.
I would love to see terminal/unix being part of the story. I realize that one can install Termux, but telling the story without it would be super attractive for developers. It would also further differentiate from iPad.
Any thoughts on this for us developers?
Estimating computing power of Fenix 6, Fenix 7 / Epix 2 and Apple Watch S8 and Ultra based on CPUs specs found by device tear downs. Comparing other HW aspects of the given watches as well.
To help myself decide if I'll keep my new Ultra or the trusty Fenix, documented differences sensors, hardware and training metrics. I think I now have an answer.
Location on Fenix 5 is quite inaccurate compared to Fenix 7 or Ultra - especially with tree cover.
Any proof for Garmin sensors being more precise?
TheQuantifiedScientist on his YouTube channel has great tests for many wearable devices and their sensors. His assessment has been very favorable for AW Ultra on HR, location and sleep when compared to Garmin devices: for sleep tracking Garmin is very inaccurate, for HR and location Fenix 7 and Ultra are identical. Fenix 6 and older are poor.
Blood oxygen and temperature seems to be quite inaccurate on both.
Ultra has almost the double physical battery and may have some exclusive optimization to GPS and HR that may not come to other watches when released later this year.
I think that the iOS built-in map component does not support offline vector maps. Most apps (with exception of WorkOutDoors) use that and cannot support improper offline without Apple updating the component.
Offline map situation on Ultra is complicated. WorkOutDoors + Garmin Explore combination is a decent workaround, but nowhere as robust as Garmin Fenix. Various details may make the workaround no-go for you: do you have access to the Garmin Explore app, is having only a small map acceptable for you, is the battery life sufficient for you, is routing on watch a must have for you, …
Lack of offline maps are a showstopper for using the new Apple Watch Ultra for multi-day hiking. This post tests the only workaround against Garmin Fenix.
Check out my battery life estimated comparing AWU and Fenix on the linked post. Battery life is not the issue any more. Ultra has 29% larger battery than Fenix 6X. But at the same time, AWU has 20-50x more powerful CPU. This consumes energy if/when you choose to use it.
Having been using Fenix 6X daily for 2 years, I regard it as dumb. It is a great activity-measurement tool and trustworthy companion on a multi-day adventure. But by no measure it can be called no more smart than old Series40 Nokia feature-phones can be called smartphones.
Is the battery life enough? How to solve offline maps? Would it work for training? Would a dumb watch be better than a smart one?
Fed D&D Monster Manual TOC to Stable Diffusio modeln: GPUs said brrr on AWS and out came a 300-page book of nightmares. To take this one step further, Amazon published it. We’ll see if this “bot” will earn its keep.
Vaadin Flow works great with Kotlin.
Check out Vaadin Flow framework. Modern single page web app in 100% in Java. Everything just works. And looks beautiful by default.
Hilla is a spinoff from Vaadin - previously called Vaadin Fusion: - TypeScript + WebComponents based frontend - Autogenerated strongly typed endpoints - Automated server-client communications - Seamless integration with Spring - A rich set of UI components - Built-in customizable design system
Any guesses for GeekBench 5 scores?
My expectations: - Single core: 1600-2000 range - Multi core: 7000-10000 range - Metal: 19000-23000 range
Presentation video from GWT.create where Daniel announced Singular: http://gwtcreate.com/videos/index.html#singular
Slides from Daniels presentation: http://www.daniel-kurka.de/talks/gwtcreate15/singular.pdf
This shows how Vaadin works with Scala. Powerful combination for RIA development.
You might also want to take a look of this Vaadin theme example that demonstrates that DOM of the Vaadin widgets is optimized for easy CSS:
Take a look of Vaadin Reindeer theme: http://dev.vaadin.com/svn/versions/6.0/WebContent/VAADIN/the... You just can not write something line that in few hours...
Book of Vaadin http://vaadin.com/book has a whole chapter on this. Also the Vaadin Eclipse Plugin makes getting started with adding new widgets trivial (just "Add New Widget" and it creates a widget stub for you)
There are multiple levels of control: 1) for each UI component you can select to send events immediately to server or alongside the next "packet" sent to server. 2) as we are building on top of GWT - you have the full GWT-based RPC also if you want to do the communication manually.
Because of the server-driven architecture, you can use graphing libraries like JFreeChart easily.
This is a matter of taste - benefits of the server-driven architecture are: no limits from the server, no GWT recompilation, direct access to server-side API and resources, better security, full Java virtual machine, full tooling and debugging support. Downsides are: more client-server traffic, more data to store in HttpSession.
Vaadin is actually sending only small JSON snippets to client-side. These are instructions to browser on what to draw. Like: "add a button to layout", "change the contents of a label to say hello", etc. All rendering is done in client (using GWT). So the client defines what the button looks like, how it behaves, ...