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.

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’m not sure how safe that would be. I’m a radiologist and we practice with a principle called “as low as reasonably achievable” to minimize harm.

While ultrasound is not ionizing radiation it does cause tissue heating. 24/7 ultrasound is a huge increase from our current practice and seems medically unnecessary beyond being “cool”.

This sounds cooler than it is. I showed my son his ultrasounds… stills and videos. He didn’t care.

Be patient, I’ll bet he appreciates them later in life.

I'm later in life. It's still not that interesting.

Baby pictures are mementos for the parents, not the kids.

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.

The real question and a better post than the original post would be: Are people living in the 21st Century too easily offended?

But it's a rhetorical question...

Yeah, maybe not being offended just because of the word "simple" would be a good start.

I didn't use the word offended.

Feeling offended is a very different emotion than feeling alienated.

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.

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.

I agree it's possible. I disagree it's compatible with seeing product management as being about consistent execution of plans.

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.

Does anyone have experience with long-term usage of these automatic DB to API systems?

I always worry about change management and inefficient designs.

I can't talk about PostGraphile, but that's my experience using anything automated. Even your run of the mill ORM's drive me nuts. Abstracting out schemas is fine, but when it comes to query creation, I need to be in COMPLETE control of what is happening.

with PostGraphile you pretty much are in complete control. You're free to write your own postgres functions/views which postgraphile will expose as endpoints. you can do so such that they are standalone endpoints or sub-queries to the auto-generated table queries. you can also basically bypass all the auto-generated table queries by creating them in a schema that postgraphile doesn't introspect, and then write all the functionality you want in a schema that it will, thus getting only endpoints/queries that you wrote yourself exposed in the api.

This isn't an ORM, is it? I poked at it in an earlier (PostGraphQL) version and it feels like a query translator from GraphQL to SQL and back, to me, with no munging onto or into objects, at all. ORMs are for people who love their programming language but don't want to touch the database.

This is kinda the opposite of an ORM. Nearly everything is in the database and this is a wrapper that allows you to build your app in your database.

You're thinking of code-first ORMs (to use the EF terminology), where you write classes and the tool maps them to tables and queries.

These GraphQL tools, however, act a lot like a database-first ORM, where you provide a database and the tool generates code in a different paradigm (OO for ORMs, Graph QL here). It is indeed the opposite direction, but ORMs can work that way too.

Yeah, I guess GraphQL is delivering JSON "objects". Nonetheless, developing for it is a completely different experience from any other ORM I've ever poked at (not saying it's better, just very different).

I like hal+forms!

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?

Yeah definitely.

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

It's a great framework.