News for hackers. Stuff that matters.

Dashron

Re:Ask HN: What Are You Working On? (July 2026) on Monday July 13, 2026 @07:35AM (#48891115)
When I switched from engineering to product, I tried a bunch of different user insight tools. They all had their strengths and weaknesses, but they always felt... off. They gathered feedback well but it wasn't easy to answer the questions I was asking, and it was a huge chore to keep it organized.

So I hacked on https://inputbuffer.io and just opened it to a wider audience.

You hook up your user feedback source (via widget or API) and it will organize everything by content category (e.g. billing) or target (e.g. a specific page, API endpoint, CLI command etc).

Categorization isn't rigid, InputBuffer does its best to put feedback where it belongs and gives you a clear triage flow if you want the added control.

Once organized you can learn more via a quick analytics dashboard or by interrogating the data directly, chatting with InputBuffer to gain a stronger understanding of your product, with clear citations to all feedback.

I have had success on both small and large amounts of input, on traditional SaaS platforms, developer tools, open source projects and more.

Next up: automatically gathering user input from other platforms (like GitHub issues), and more research tools.

Re:Ask HN: Meal Planning App? on Tuesday August 02, 2022 @10:09AM (#32318654)
I've tried a lot of different app, and mealime is the only one that clicked with me.

1. I'm reminded to pick meals on Sunday 2. I select a couple of interesting recipes and it creates a grocery list. The recipes are varied but not too varied to induce choice paralysis. Dietary restrictions are automatically applied from your account settings. 3. It has its own cooking mode with great features like "every step tells you exactly how much of an ingredient you need" and "hold your hand over the screen to progress" so I don't get crap on my phone.

I've been using it for over a month now and am still happy with it.

I'm sure it would amplify my anxiety!

My son was IVF so we already have images of him most parents would never see (e.g. blast stage), but having a long term ultrasound time lapse of those 9 months of my son would be pretty amazing.

I didn't use the word offended.

Feeling offended is a very different emotion than feeling alienated.

It's not a good feeling when you find something "simple" to be hard. Few tasks are easy when you're a new programmer still wrapping your head around conditionals.

If my docs might be used by a new programmer I try to avoid alienating my users with the word simple.

Re:Node.js 13.0 on Tuesday October 22, 2019 @04:48PM (#21328356)
I looked at the code (but didnt try it) and I think this only affects console output, not any return value that you would parse.
Re:Don’t work “remotely” on Wednesday November 21, 2018 @09:26PM (#18507524)
Ah, I read that phrase differently, but think I see your point now. There's definitely a type of "plan" that can be very micromanagey, and problematic.

I've lucked out and most plans I've worked with are super, super high level and gives everyone a lot of freedom.

Re:Don’t work “remotely” on Monday November 19, 2018 @12:49PM (#18488171)
He goes in more details about product management here: http ://blairreeves.me/2018/10/16/whats-a-senior-product-managers-job/

I don't believe his view conflicts with yours.

I think it's very possible to have someone present to help define value and priorities, and focus on the people part of getting shit built, while giving engineers a lot of creative involvement and ownership.

Re:PostGraphile Instant GraphQL API for PostgreSQL Database on Monday January 15, 2018 @09:55AM (#16150843)
Does anyone have experience with long-term usage of these automatic DB to API systems?

I always worry about change management and inefficient designs.

Re:Show HN: RESTful Doom – HTTP+JSON API inside Doom on Friday August 04, 2017 @01:09PM (#14930133)
I like hal+forms!
Re:Show HN: RESTful Doom – HTTP+JSON API inside Doom on Friday August 04, 2017 @12:36PM (#14929893)
Business logic should be hidden behind the API and the representation. Just like a website, actions are presented when the business logic allows it.

Other API calls depend on the purpose. If its part of the business logic, it's probably back end and hidden as described above.

If the other API call simply powers the UI, you might keep it in the client. One example is autocomple for facebook friends. The client can call facebook for a list, let the user select their friend, and then send that friends info to your API.

With that said, I'm not sure how either of those are "non-RESTful" so maybe I missed the point of the question?

Re:Using A-Frame for WebVR and AR on Friday April 07, 2017 @03:51PM (#14062987)
Yeah definitely.

I completed https://aframe.io/aframe-school via https://webvr.rocks/firefox on my PC & Rift.

It's a great framework.

Re:Never ever write software for Oculus on Monday April 04, 2016 @08:28AM (#11421315)
Looks like Steam has similar conditions: http://store.steampowered.com/subscriber_agreement/

"YOU AND VALVE AGREE TO RESOLVE ALL DISPUTES AND CLAIMS BETWEEN US IN INDIVIDUAL BINDING ARBITRATION."

"You grant Valve and its affiliates the worldwide, non-exclusive, right to use, reproduce, modify, create derivative works from, distribute, transmit, transcode, translate, broadcast, and otherwise communicate, and publicly display and publicly perform, your User Generated Content, and derivative works of your User Generated Content, in connection with the operation and promotion of the Steam site."

One key difference is which services this applies to.

Steam: "in connection with the operation and promotion of the Steam site"

Oculus: "in connection with the Services". Where services are defined as "use of physical goods, platform services, software, websites, applications, and content"

Re:Node v4.0.0 on Tuesday September 08, 2015 @11:11PM (#10189457)
Or if you want to use native promises, I threw this together

https://github.com/Dashron/roads-coroutine

This proposal is more in line with the system you describe (except null instead of undefined). https://tools.ietf.org/html/rfc7386

I prefer it, and think it's much easier to understand.

Re:Dropbox Chooser on Thursday November 15, 2012 @02:41PM (#4790359)
One bonus is that the transfer from Dropbox to a web service is going to be way faster than from your computer to that same service.

Additionally, the user can navigate away from the page, close their browser, lose internet, etc. and the transfer will still happen.

Re:Bifocals.js - asynchronous, nested view rendering on Wednesday October 24, 2012 @03:38PM (#4694648)
Future progress on this can be located at https://github.com/Dashron/Bifocals/issues/8 if you are interested.
Re:Bifocals.js - asynchronous, nested view rendering on Tuesday October 23, 2012 @07:01PM (#4690799)
I messed with a couple of highlighters and they all had issues highlighting everything correctly.

I might turn them all into gists, but I am going to talk with the rainbow.js author before I do.

Hopefully this will be fixed soon!

Re:Bifocals.js - asynchronous, nested view rendering on Tuesday October 23, 2012 @05:58PM (#4690569)
Ugh where the hell does that happen?

My linter usually yells at me, I'll dig around and fix those up.

Re:Bifocals.js - asynchronous, nested view rendering on Tuesday October 23, 2012 @05:56PM (#4690559)
Hey all, I'm having issues replying to comments so I've been emailing jasonmoo to get everything lined up properly.

Hope I can answer any questions you have.

Thanks, Aaron

Re:MVC, MOVE - Or Simply A State Machine? on Tuesday July 03, 2012 @02:34PM (#4195491)
Wow, Resource-View-Presenter is exactly my framework.

Except I call my presenter layer "resources" and my resources "models".

The state machine in my framework is a system within the view layer so you can asynchronously re-route through the "presenter" and re-use code.

Re:MVC, MOVE - Or Simply A State Machine? on Tuesday July 03, 2012 @12:34PM (#4194831)
I might be reading the blog wrong, but it seems he is using the MVC view (templates separated from the logic and sent to the user) and the user interface interchangeably. These are two very different things.

The interface the client uses is always going to be some sort of state transfer system, moving between different pieces of content and displaying elements to transfer between content.

Handling these views on the back end is an entirely different issue.

State machines are useful on the back end, but it can not be used between requests without causing headaches.

I have been experimenting with state machines in a node.js framework to handle asynchronous sub-views (https://github.com/Dashron/roads). It makes development incredibly simple, and breaks up the code so that you can have traditional, or single page apps with the same codebase.

I don't think a state machine would be useful at a higher level than this (in the backend) but I will put more thought into it.

Re:REST worst practices on Friday January 20, 2012 @05:29PM (#3491515)
Put is supposed to be Idempotent (http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.1...).

calling "PUT a=b&c=d" three times should be identical to calling it once. So any time you let the system generate an ID for the resource you should use POST.

PUT works in creation when you know the id beforehand.

I have not worked with amazon s3 but I hear they handle this well. You PUT a file to a url containing the file name. The first PUT creates the file on their end, any future PUT updates that file.