babbledabbler

I wonder how hard it would be to use AI to generatively interpolate the images so it could be a video stream.

Woah it even has a w for wa-pi-rio.

Yea I start to load the chat and then was like wait a sec and noped out.

I'm working on an app to address this issue. While putting a cost calculation is a good way to raise awareness, we take a different approach to a solution.

It's called Meet Robbie (https://meetrobbie.com) and we give you an agenda with timers, minutes, and action items and you can use it directly in Zoom.

It's main use case is for recurring meetings where you have a list of business to get through. It encourages common sense things like having an agenda, being mindful of time, and keeping organized minutes.

We just released our so you can try it out. Would love any feedback and thoughts on our approach!

Thanks! This has potential. I'll play around with this when I have some time.

Thank you! That's a good idea. I have fields for user_id and organization_id that I omitted.

What would you rename type to?

Now here's what I'm thinking

id: uuid | name: string (ex 'Google', 'Microsoft') | type: string (ex 'calendar','task-management'')| properties: jsonb

say --rate=500 "Peter Piper picked a peck of pickled peppers. A peck of pickled peppers Peter Piper picked. If Peter Piper picked a peck of pickled peppers, Where’s the peck of pickled peppers Peter Piper picked?"

Yes I started using this in the past year. It dramatically sped up my watch/test cycle on mac.

It seems like something that shouldn't be necessary on Mac with docker so I hope they just make it a standard docker feature.

I don't really find these considerations frustrating just a bit tricky but regardless definitely agree with GDPR and on board with keeping PII secure from the get go.

I'm still having a little trouble grokking when an ID becomes exposed or shared so I guess I'll just have to read up on this as it's certainly important.

In our system I realized user IDs are not shared nor linked to (at least not yet) so in actuality the case where there's a URL with a UUID representing a person does not occur. Content generated does not reference UUIDs for persons either. There are URLs with UUIDs representing other types of resources.

By API key I take it to mean an access key for an external reference. That's a good idea for replacing the PK integer with a PK UUID but keeping an external UUID field. That would satisfy the concern with maintaining integer sequences and migrating data.

Anyway this has been helpful so thank you for sharing your thoughts and I have some things to look go on to stay in the good graces of European regulators.

Mainly portability of data and options for the future. I'm all on one postgres instance right now and don't plan on breaking it up until necessary. If at some point I need to take a table and move it to another type of database I want that migration process to be straightforward. If I have integer keys with sequencing behavior I anticipate having to do that porting. That internal key would then become external to do the lookup and if it's an external key I want it to be UUID for security as well. Integers as IDs are guessable so I want to keep them internal.

I'm really not sure what google is thinking with this one. It's not the biggest money maker but google domains is viable and a really easy to use product.

Wondering what other core web services google may sell off.

I'm not so much concerned with figuring out scaling in terms of volume as I expect to be able to handle millions of rows in a single DB and that would be an implementation detail and fine tuning. I'm more concerned about scaling in terms of complexity and keeping the system easy to reason about when more people, tech are involved.

Lets say I have a <CAR>-[1:N]-<TRIP> in two tables in a relational DB. This works fine at first even for millions of rows as you say.

At some point in the future it makes sense to have these two entities managed by different team/services/db. Let's say TRIP becomes a whole feature laden thing with fares, hotels, itinerary, dates. So I need to take this local relation and move it to different services and different DB.

If I had been using an integer PK/FK this would be a more complicated migration than if I used UUIDs.

My assumption is that we would not want to have a sequenced integer key used in a distributed system.

In other words it seems safer bet if there's a possibility of needing to move to a distributed system to use a UUID for the key from the beginning.

I'm simplifying a bit for brevity and we can do some abstraction to handle it so it's not that the framework is simplistic. I'm just having trouble justifying adding this complexity with two types of IDs.

This was generally the reason I went with numeric ID as PK originally. It makes working with and analyzing the data as well as cross referencing relations easier.

For all my tables I have a base schema that looks something like this.

id: integer sequence PK uuid: uuidV4 created_at: datetime updated_at: datetime

The concern I have is when I have to distribute my system when scaling. Those numeric IDs will have to be replaced with the UUIDs so I figure I might as well do it now.

I think you raise some good questions around IDs and PII and we definitely will be tackling GDPR sooner or later.

I don't quite follow on the European regulation issues raised by using as a UUID in a route and that being the PK of the record.

I know you should not expose PII or any information that can be used to identify a person, however, in our case any route is behind an authed login on an SSL connection which encrypts the path (we don't use query params).

The only place that contains data that ties a UUID to a person is in the database. This would be the case whether we used a PK as an integer or not.

Could you elaborate or share any resources around dual IDs DB design for PII compliance? That would be super helpful.

Regarding framework hacking or workarounds, I have a principle to not go against the grain of a framework. The reason for this is that modifying/hacking adds complexity when building on top of it or onboarding other software engineers. If necessary I'll do it as a last resort.

Probably when there is some downtime or as the opportunity presents.

I would use a date field to do ordering or a sequenced field when needed.

I actually have been using a combination of a numeric integer ID as the PK and a UUID as a lookup field to do routing lookups etc. for this purpose in Postgres backed app I'm working on.

I found this approach to be more trouble than it's worth and plan on switching to a UUID PK key and doing away with the integer sequence.

Here are the complications I ran into:

The libraries I'm using for the ORM and API are designed to work with a primary key for single record get access. For example they want you to do `resource.get(ID)` where ID is the primary key, however, I now have to do `resource.find({ where: { uuid: 'myuuid' }})`. This is for all resources on all pages.

In Postgres, the integer PK sequence has a state that keeps track of what number it's at. In certain circumstances it can get out of sequence and this can trip up migrations.

We already have created_at and updated_at fields and these are probably better for ordering than the sequencing.

Had I to do it again, I would just use UUIDv4 until it runs into issues and either date fields or a sequence where necessary. If anyone has better ideas I would be most grateful as this is something I go back and forth on.

Is there a reason web scrapers aren't used for public sites with content? It seems like this would avoid the pitfalls of APIs and changing terms and prices?

...and still getting clicks 16 years later. Respect.

It seems this is a case of poor decision and communication management rather than a machiavellian plot, however, it's no less harmful or toxic in the outcome.

I'm actually working on an app for organizations to make clear, fair, and transparent decisions systematically so things like this don't happen.

Same thoughts here. I think it's great that people can make extensions and apps for new and varied experiences, but the current HN is dang near perfect IMHO. Simple, intuitive, fast, does what you expect it to do. Nothing less nothing more. It's reached its final form for me. Everything else is fan fiction.

It's natural to take criticism of your work personally so I think the first thing is to accept the initial emotional reaction as "ok" and not something to beat yourself up about.

The next step is to tame your emotional response. It's almost never a good idea to act based on emotions so you first need to get a level head before responding. You can journal, meditate, go in a room and rage out if you need to, but just get that chimpanzee in your brain to settle down. Not easy but has to be done if you want to transcend whatever is coming your way. Sometimes you will fail but there's always next time so just keep at it.

Once you've settled down, now it's time to rationally consider the content of the critique and decide how to respond. Criticism can come in many different shapes and sizes: valid, invalid, clear, vague, harsh and nice, well timed, ill timed. Unfortunately, some people can be downright mean so handling harsh and uncivil criticism is a skill that takes time to master. If you notice most highly successful people, they take nasty criticism like water off a duck's back. That being said, it's really unacceptable to have people making snarky comments on your work and if it's a pattern there, I'd consider finding a more nurturing place to work.

Once all that's done, decide whether the argument is valid and if so make the adjustment in good faith. If not respond, with your reasons respectfully and with an open mind. They may respond in turn, and if so you and your colleagues will have achieved a harmonious spirt of working together towards a higher truth and you will benefit in ways that cannot be overstated.

Good point. "communication" should also be on the list. I don't think storage is technically the tradeoff in this case even though it's S3. It's the traffic between those components that's costing them.

Breaking things into tiny functions and putting them on many different servers incurs tradeoff costs in both complexity and compute. There is a complexity cost in having to deal with the setup, security, and orchestration of those functions, and a compute cost because if the overall system is running constantly it will be less efficient and therefore more expensive than running on one box.

This is what I was told by startup mentors and have come to appreciate as well in my experience.

I would also add that while there is some small risk of someone least copying your idea, it's not necessarily a bad thing. If someone else is doing it, it validates that there is a market. You can also expect that if your idea becomes successful it will be copied at some point.

There's actually much more risk in not learning the practicality of it and refining it by talking to as many people as possible than there is from it being copied.

Somebody should make an AI service that automatically files appeals. I suspect that the cost of the appeals process would negate the savings they make from auto-denying claims.

I would checkout Vue. It's much more user friendly IMHO.

This is something I wish was more widely discussed. Abstract principles are only templates for how to act, not prescriptive rules on what to do.

Much like a craftsman uses various stencils and measures to guide their craft, it's not simply using the stencil that is necessary but applying that stencil with skill and judgment, and when working with others, sharing those stencils kindly.

This is a common pitfall for software engineers and one that is easy to fall into especially if you haven't gone through it before.

Dysfunctional technical systems are symptoms of dysfunctional political systems.

If the political system is not rehabilitated, the technical system will continually evolve dysfunctional traits no matter how much development effort is spent. It falls to management to ensure the political system is functioning properly but software engineers should keep this in mind to avoid getting caught up in the gears of such systems.

It's crazy that our existence is in large part due to the very kinds of mass-extinction events the we could be triggering.