Hacker News new | past | comments | ask | show | jobs | submit | 1a527dd5's comments login

I just wish the default wasn't bash. GHA with pwsh is a much better experience.

https://www.vantage.sh/blog/amazon-s3-tables#s3-tables-cost

I can't make head or tails of the beginning of this sentence:-

> Pricing for S3 Tables is all and all not bad.

Otherwise lovely article!


"all and all" is a typo for "all in all" which means "overall", or "taking everything into consideration"

So they are saying the pricing is not bad considering everything it does


There is something here that doesn't sit right.

We use BQ and Metabase heavily at work. Our BQ analytics pipeline is several hundred TBs. In the beginning we had data (engineer|analyst|person) run amock and run up a BQ bill around 4,000 per month.

By far the biggest things was:-

- partition key was optional -> fix: required

- bypass the BQ caching layer -> fix: make queries use deterministic inputs [2]

It took a few weeks to go through each query using the metadata tables [1] but it worth it. In the end our BQ analysis pricing was down to something like 10 per day.

[1] https://cloud.google.com/bigquery/docs/information-schema-jo...

[2] https://cloud.google.com/bigquery/docs/cached-results#cache-...


I'm amazed that this has reached the almost-top of HN.

It's a very confused article that (IMO) is AI Slop.

1. Naming conventions is a weird one to start with, but okay. For the most part you don't need to worry about this with PKs, FKs, Indices etc. Those PG will automatically generate for you with the correct syntax.

2. Performance optimization, yes indices are create. But don't name them manually let PG name them for you. Also, where possible _always_ create the index concurrently. This does not lock the table. Important if you have any kind of scale.

3. Security bit of a weird jump as you've gone from app tier concern to PG management concerns. But I would say RLS isn't worth it. And the best security is going to be tightly control what can read and write. Point your reads to a read only replica.

4. pg_dump was never meant to be a backup method; see https://www.postgresql.org/message-id/flat/70b48475-7706-426...

5. You don't need to schedule VACUUM or ANALYZE. PG has the AUTO version of both.

6. Jesus, never use a DEFAULT value on a large table that causes a table rewrite which will cause you downtime. Don't use varchar(n) https://wiki.postgresql.org/wiki/Don%27t_Do_This#Don.27t_use...

This is an awful article.


> don't name them manually let PG name them for you

If you care about catching stuff like unique constraint violations in your code then you should know what the indexes are named.

Always name your indexes and constraints. They're part of your code. How would you catch an exception that you don't know the name of?


You don't need to know the name; I prefer to go by the error code PG spits back at you. In this case 23505.

https://www.postgresql.org/docs/current/errcodes-appendix.ht...

That is much more flexible than hard coding the name.


If you have multiple unique constraints in the same table then it will spit back the same error code. I want to know the name of the specific constraint that was violated.

Always name your indexes. Always name your constraints.


I mean if you have that many violations that points to other problems, but sure if you are in that situation I can see how catching by name might be helpful. It's not a panacea.


It's not that hard to just name the things you care about instead of relying on auto-generated stuff from the database. PG lets you do this easily.

> if you have that many violations that points to other problems

No, it doesn't. This is a sophisticated design choice. You might be out of your depth here.


Okey dokey mate, you do you. Have a great one.


This is a great book that explains PG in a step-by-step way. I learned a ton from it

https://theartofpostgresql.com/


I'm aware of it thanks.


Also useful for migrations, especially if you support multiple DB backends.


> 4. pg_dump was never meant to be a backup method; see https://www.postgresql.org/message-id/flat/70b48475-7706-426...

Those are very recent emails that don't say anything about what it was originally meant for, just that nowadays there's better options.

Though really the part they quote called it a backup tool, that does imply it was originally meant to be a backup method.


> I'm amazed that this has reached the almost-top of HN.

The article is objectively bad; the subject is clearly something a lot of people think about, myself included.


They might not be disrupting them, but they are definitely causing competition in the market place again.

My main bank account is with Halifax, everyday spend is with Starling. Then Monzo for anything risky.

Before Starling/Monzo the Halifax app was _crap_. Barely got any updates and was very basic.

Now? The Halifax app is on par with the newer banks, and sometimes even release new features before (e.g. scan cheque in to deposit).


That exactly. Fintech forced Financial Institutions into Digital Transformation. Now they have caught up, there is no "next big thing" for Fintech. Crypto might have been it, but it killed itself by terrible UI and a never ending stream of scams and frauds. I believe there is an AI Agent Internet of Money to end Ad Revenue, but haven't found the arbitrage model yet.


Halifax is owned by Lloyds banking group, and their current app is just the exact same Lloyds app with a different logo. I know because I bank with both and the apps are identical.

Previous to the merging of online services, you are correct that Halifax had its own app and it was terrible. But at that time Lloyds had a great app, they just hadnt unified the back end tech of all the different bank brands they own.

It wasnt disruption from startups that caused the improvement, it was the parent company taking its time to merge the decent tech it had developed for itself.


Yeah I feel like Monzo and Starling really forced the high street banks to level up their game. A friend of mine was a PM on an app at one of the big high street banks and they said the instruction from the top was explicitly to be like Monzo, and they did iterate, get better at app development, and ship a bunch of features that people like (spending notifications, in app card freezing, etc).


Interesting... We've had scanned check deposits at Chase (US) for at least 15 years, I think.


Bear in mind that's a measure of how backwards US banking is, not how advanced.

In the UK, I can't remember the last time I wrote or received a cheque. Maybe twice in the 17 years I've been living here, and certainly not in the last decade.

So with UK cheque usage being a tiny fraction of the US rate, there's simply no demand for it in banking apps.


Cheque use in the UK is now around two per year per person. (This includes business-to-business cheques.)

The over-65 age group is most likely to use them, and least likely to use an app, so you can see why it wasn't a big priority for most banks.

It's been at least 15 years since the banks stopped giving account holders chequebooks by default. If you want one you have to ask.


I get a couple of cheques a year from family in the UK. It's an infrequent transaction but an important one, and cheque scanning is actually the only reason I maintain my legacy bank account.


most countries abandoned checks at least 15 years...


ppl dowvoting facts now


> Has there been any other behavior like this in the past where a company "shut themselves down" to make a big political statement and then almost immediately undid the shut down?

OnlyFans did something similar: https://en.wikipedia.org/wiki/OnlyFans#Restrictions_on_porno...


That wasn’t a political statement. Per your link, it was a belief that that could not continue the credit card payments while staying in compliance with the law.


Probably not the place to post this feedback, but in general I get excited about what Cloudflare have been releasing in 2024. I'm borderline desperate to try them out in a business setting.

The only thing that really stops me is the horror stories I hear about random billing issues and on top of that account closures.

That is something I'm _never_ worried about with AWS.

On the off chance that someone from CF is reading this feedback.


This is pretty cool, I ran it against one of a largest customer sites and it was very interesting to see how the page all interconnects. I'm pretty sure it can be used to spot architecture/performance problems.


The first and immediate difference for me is the ability to recall the name. I can recall Postman/Insomina fine, and now for API Parrot. I'm never going to be able to recall mitmproxy2swagger.

Unfortunately, names matter.


Thanks 1a527dd5.


Ha! Nicely played. That was out of purely laziness. I don't like using one handle across sites, so I take the first 8 chars of (New-Guid).ToString() and then dump it in my password manager.



a real pitty that this was not xkcd 1111


As someone who uses mitmproxy and swagger quite often, I actually think the name isn't so bad. I haven't even looked at the readme but I already know what it does, how to run it and what output to expect.


I often forget the name of things, sometimes even the big ones. GitHub search is one of the primary ways I rediscover them. "reverse-engineer API" returns mitmproxy2swagger as the third result, and this is how I found it last time I needed it.

It is a bit frustrating when a project on GitHub doesn't have good tags or searchable keywords, making it harder to find.


The first year was the best year for me. It was really fun and I think I got 22/24 days done. After that my participation rate has been shocking, I really want to do it but I get this weird anxiety that I'm not quick enough.

Which is weird because that is not a thought that entered my mind when I did it for the first time. It was pure fun!


Just give up on the main leaderboard. Maybe join another, preferably with people who share your time zone and schedule.


Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: