Nican

I just have an old Dell computer [1]. They are pretty small, quiet, has an SSD, and I do not need to fiddle in having everything compiled for Arm.

I would also put your app behind CloudFlare.

Also- if you are able to afford an intel NUC ($200?), and the app is low resources enough to be able to run on a Pi. You could also consider getting a VPS ($10/month).

[1] Something like https://www.newegg.com/dell-optiplex-7090-business-desktops-... - but older, and found on a local recycling center.

I was going to answer that the answer is column families [1], but I just realized that is a CockroachDB-specific feature.

[1] https://www.cockroachlabs.com/docs/stable/column-families.ht...

Price decreases as time passes? It is called an Dutch auction. [1]

The most famous example I can think of is the flower auction/Amsterdam clock.[2]

[1] https://en.wikipedia.org/wiki/Dutch_auction [2] https://www.youtube.com/watch?v=uAdmzyKagvE

Cheap DNS registration, and being able to keep it at the same price.

What I am wondering right now is if there is any regulation about buying a domain, building a popular product on top of it, and then having your registrar keep increasing the renewal cost. (Something that I never considered, but now looks possible)

For those who do not remember, Google did an auction for .dev domains when it was first released in 2019. I think it was something like that every week the price was halved until it reached the $12/year.

I bought a .dev domain from Google, when the auction was at $200/year. Every renewal period has been $100/year. If there is a way to decrease it to $12/year, that would be great.

EDIT: Looking at other comments on this thread, looks like that Google is dynamically price adjusting renewal costs? I am sad that yet another pillar of the original free internet seems to be falling even further pray to capitalism.

That is the thing that made me realize that this is not an official GitHub product.

Wow! I really like this project. I have been loving actor systems, and your project brings a lot of interesting concepts together.

I do not have much of anything to say, but I did come up with an idea. One thing that Fuchsia (operating system) does is that parents are able to lock down the permissions when spawning childs. For example, if a child is spawned with no I/O permissions, that child will have all those permissions removed, and any child that spawns from that will have the same restraints.

Could Lunatic support something like this on the far future?

EDIT: I just read the FAQ and looks to be heading that way. Awesome.

I know nothing about ClickHouse, but how many cores are being used for these queries? And what is the core processing frequency?

I would think ClickHouse is tuned for analytics workloads, so it will throw plenty of cores at the problem, and not care much for the overhead. Meanwhile, I believe PostgreSQL is more tuned to transactional workloads, where it will not pay the query parallelism overhead, but optimize for multiple parallel workloads.

This is actually what the Azure Portal does [1] for embedding 3rd party applications. They even developed a custom HTML language to describe how to layout applications to give a consistent look.

The downside was the portal started to become slow, and sometimes would have 20+ iframes open.

[1] https://github.com/Azure/portaldocs/blob/main/portal-sdk/gen...

This is only a personal project. I am building a Twitter graph tool. It created a 2d graph of all of your followers (Up to 20,000 followers), and calculates proximity based on shared followership.

[1] https://twitter.com/Nican/status/1592010109202616322 [2] https://graph.bunnypa.ws/

Awesome! I have seen PlanetScale hype up this release for weeks, and glad to finally be reading about it.

My initial thoughts after reading the blog post, just to poke holes in their new product:

1. Costs. This can save time on read, but it is also introducing additional writes to the database, that can be pretty expensive. PlanetScale can scale horizontally, but have to watch out how much it is going to be paying for the extra machines. (Albeit- machines are usually always cheaper than developers)

2. Consistency. It was not clear if it is going to make committing transactions slower to keep all the views up to date, or if the materialized view is running slightly behind real-time.

2a. And how does the materialized view handle large/slow transactions? Is there going to be any kind of serialization locks? Are the views correct inside of the transaction?

3. Predictability. Query planning is a necessary hell, and different queries might have different patterns that might introduce slightly different materialized views, that could have been maybe served under the same view. Increasing the cost.

3a. SQL Server took a slightly different route lately for performance, in which queries will have different plans depended on the table statistics. I wonder how such a feature would play with Boost, and if slightly different query plans might generate different materialized views.

As with any of the other solutions proposed, it would take a huge organization level shift for everyone to standardize under one RPC standard (including monitoring).

It is not for the lack of solutions in hindsight, just the constant feature creep and microservice development blind sighted everyone to large organization problems.

I had my own hell with Microservices during my last big-corp job. Having to deal with API migrations was a nightmare, because other teams never wanted to spend the time to switch to the newer versions, and it was hard to even figure out where in their codebase the API calls were being made from.

There is definitely still a lot of opportunity to breach the boundary between development and production to understand distributed systems

Huh- Running Postgres at home, while running the web server on Digital Ocean. I would think that since running several round trips to the database for every web request, it would make more sense to run the entire web server at home?

That caught me off-guard as well. I only ever written one thing in Haxe, but the experienced was mixed. It worked, but it also kind of painful to work with.

For context: Haxe is a programming language with the main purpose to have several compile targets for many programming languages.

Glad it is working for them.

Mastodon may not have the better interface, or the better community, or it may not yet be the most intuitive to use.

But I want to invest my time to help Mastodon reach the critical mass it needs. I would love to have a social network not controlled by capitalistic needs, and let open source developers help evolve it.

I used Dart for a project some 8 years ago. There used to be an easy to use Dart Editor that I used and one day it just stopped working, and stopped getting updates.

Google did not provide any good alternatives, and I just gave up on the language for the lack of developer support. I have not looked back since.

Jeff Atwood 5 years ago: "the Qualcomm hardware people told Google internally they were 5 years behind Apple on hardware. This was about 1.5 years ago, but I believe that's about right." ( https://twitter.com/codinghorror/status/1050538041796788225)

And benchmarks continue to show: https://twitter.com/slightlylate/status/1584350796233117696

I have not used moment.js or other date libraries in a long while. But how does this compare to Luxon? (https://moment.github.io/luxon/#/why)

I had quite some pleasure working with the Source Engine gameplay code. (Some 10 years ago now)

https://github.com/ValveSoftware/source-sdk-2013

It is not that the quality of the code is high, but just that it is well organized, and everything seems like it was written by a beginner. That makes it wonderfully easy to read and follow the logic.

Since have played around with the Source Engine, I follow the KISS principle with coding with high priority. Rarely trying to be clever, or try to over-do abstractions.

Probably trying to get rid of people using their service like this: https://www.reddit.com/r/DataHoarder/comments/ufa4v4/google_...

Planet Money did a podcast on the subject: https://www.npr.org/sections/money/2018/08/01/634737852/epis...

There is a fixed rate between postal offices to ship overseas, and it may make the shipping cheaper when coming from China.

I am having quite a good time with CockroachDB. It has been mostly set-and-forget, and it auto-balances, and does rolling upgrades pretty smoothly.

Also worth looking at KQL: https://docs.microsoft.com/en-us/azure/data-explorer/kusto/q...

I am a vivid Telegram user, and it is my primary method of communication with friends. The Telegram communities are so large, that you are going to find all kind of people there. (They have claimed to have 500+ million users)

I am in over 100 chat rooms of varying sizes. Ranging from groups with 100+ members, in which I usually just ignore, and check from time to time to see what is going on. Groups of 20-100 members in which more close friends keep together, and is more similar to IRC chatrooms with tech talk and the ilk, and then a then a lot of groups with 5-20 members, in which friends organize parties, going out for dinner, etc... (I organize my chat rooms into folders for ease of access)

Telegram has been my favorite form of communication because of great performance, very good sync between PC/mobile, great search (I can find messages from 5 years ago with no effort!), and ease of use. My experience with Telegram pales in comparison with any other chat program I have used for how I like to stay in touch with friends.

Just being "Postgres" is not simple. Both Spanner+CRDB provides some custom domain specific language that helps the data distribute itself around the cluster (or the world). Or for example, change the primary key of a table, so that the database can change the distribution of a table without having any down time.

I feel like the usual "lift and shift" claims that Cloud providers claims never goes as planned, and it is not something that you can just easily find by just reading documentation. For example, only after I started using CRDB, I found out that case-insensitive indexes is not yet implemented.

But I have been using CRDB+k8s for >1 year now, and it has been a great database. Basically 0 downtime, with minimal effort, including database upgrades.

There are two ways I see databases doing paxos. The basic way, like some databases like Percona, basically is a single raft across the whole database. It can help with high availability, but the database scale is still kind of constrained to the capability of a single writer.

What you really want is databases like CRDB/Yugabyte/TiDB, which are sharding+raft. Tables are sharded into 128MB chunks, and each chunk has their own raft. The database handles transactions, distributed queries, and auto-balancing transparently.

I work at at a large corporation, and that is one balance that I am also constantly fighting and never seem to get it right. Having to provide a "Business justification"/OKRs for every technical feature has been soul draining experience, and while I can still make progress in making the product and drive the business forward, I have a hard time justifying spending the time in the little details that I would consider what makes a product really great.

I feel like the cycle turned one of making power point presentations of how the product has all the required features, but the overarching story and experience does not feel quite right. And I have been looking for advice on how to convey the importance to polish up the product.

My knowledge about kernels is very limited, but is this not the whole principle behind Google's Fuchsia?

I think the appeal is with Jupyter [1] notebooks. Python is not about performance. Usually numpy (or other libraries) that does the heavy lifting on another language anyway.

But having the Jupyter notebooks allows for intractability with the data. Make changes, and see how it affects every step after it.

[1] https://jupyter.org/