Live data from Hacker News

Bluesky migrates to single-tenant SQLite

github.com

151–160 of 247 posts

Re: Bluesky migrates to single-tenant SQLite

#151
post #99
post #76

Earlier quoted context omitted.

They have over 1.8 million users currently, or do you mean PDSes specifically? Federation is in open beta on a test network, you can try it out today if you'd like.

I have been on the wait list since they launched. They seem to mostly rely on invites.

I have a few invites. Email me and I'll pass them out. :)

Re: Bluesky migrates to single-tenant SQLite

#153
post #123

Earlier quoted context omitted.

That. And none of the big social media platforms were big at the start either.

Yes but 1.8Mi at a time where people are longing for a Twitter alternative is just leaving money on the table

There are two usual strategies for growing: 1) low cost, organic and slow or 2) high cost, throw a lot of money at advertisement, saturate all media, grow quickly or bust.

The exceptions are those rare products that despite a low cost marketing sell themselves so well that their organic growth is fast and in a few months everybody use them.

Maybe Bluesky don't have the money to advertise or is not compelling enough. As one data point: I know about Mastodon but I think that I learned about Bluesky only today. I went to their site and there is nothing to explain how it works except that it's some social thing. I learned more by reading the comments here. Apparently it's being marketed at a very low cost.

Re: Bluesky migrates to single-tenant SQLite

#155
post #36

Earlier quoted context omitted.

don't know why, but recent teams around me have always made strict rules about number of commits in PRs. I just wanted to tell them the same thing you said: "Why don't you just look at the diffs?" curious for other opinions. (sorry not really about this particular topic)

Commit and push often. Put a novel explaining yourself in the PR. And that's enough IMO.

> Commit and push often. Put a novel explaining yourself in the PR. And that's enough IMO.

Someone reading the git changelog 5 years down the line most likely wouldn't be able to find your "novel" in the PR and definitely won't appreciate if instead of a "novel" you ended up with a "short call" with the assigned reviewer explained what you actually did in your 50 "wip" commits.

Re: Bluesky migrates to single-tenant SQLite

#160

Earlier quoted context omitted.

I prefer to have clear commits that tell a tidy story. For example: * Refactor function `foo` to accept a second parameter * Add function `bar` * Use `bar` and `foo` in component `Baz` to implement feature #X If you give me a commit history like this, I can easily validate that each step in your claimed process does what you describe. If you instead give me a messy history and ask me to read the diff, you might know…

Funny that two of your commits don't actually tell us why they exist, one simply describes the diff (which you should never need lol?) and the other proxies that responsibility to some other system. You could have simply randomized the text in each commit, put the ticket id and the one "why" in the merge commit body and gotten the same end result amount of real information in the end.

I like to leave comments like this too:

loop i up to n times

break when false

check value returned is not null

Post reply on HN