HN user

sj26

59 karma

http://sj26.com

[ my public key: https://keybase.io/sj26; my proof: https://keybase.io/sj26/sigs/68ZmxMa5wf6HdTBsDF9Szek42DNz7pnWOohdGEiOMeI ]

Posts0
Comments21
View on HN
No posts found.

I'm Sam, a founding engineer still at Buildkite. I've been quite vocal that this was short term gains for long term pains. We're in the process of fixing this - we're working on a free tier and a more accessible paid plan for start ups and scale ups. I want to build tools for everyone, not a select few. Stay tuned. In the meantime I would be happy to have pricing conversations where our pricing doesn't make sense: sam@buildkite.com.

Amazon Aurora DSQL 2 years ago

Interesting discovery:

PG::FeatureNotSupported: ERROR: ddl and dml are not supported in the same transaction

Hiya! I'm the maintainer. It's true I don't do much to it these days. But that's because it's complete. There are lots of things I would love to do to improve it. But none of it would dramatically improve what it does. I fix things when they break. But if it ain't broke...

Happy to answer any questions, or be persuaded that something is broken or would be a dramatic improvement :-)

It Depends(tm).

If you're using a system which is built for distribution, random is great.

When you're leaning on a Postgres database which has powered your startup through scaling but expects right-leaning btree indexes, it's a bad time.

Rearchitecting to use a new data store is ideal, but often impractical as an immediate step. UUIDv7 is a great increment walking that road via sharding etc.

Cost/benefit.

There are always going to be security holes in anything we make. We can be a bank and focus two feet ahead on making sure everything is as secure as possible, or stay aware of security (and not do anything stupid) while moving fast enough that any flaws are irrelevant/fixed when exposed.

It also highly depends on how much risk you're willing to accept. For the average rails app, absolute security is not as important as moving fast. Be an adult and make adult decisions about your tools and processes to suit your circumstances.

This was my first thought, and seems likely. They do several forms of analysis on their cache. It could even be some engineers running tests or queries that require rendering the page or at least bootstrapping the DOM.

We used Slim for findthin.gs—it's faster, has much better whitespace control, and, imho, better achieves Haml's reduce noise, increase beauty aims. But there's no contest about Sass and CoffeeScript being amazing.