nrjames

I've been excited about Kuzu DB as a SQLite-style graph database. It looks like the devs are moving on to something else and no longer will support it, as of 10 October.

Their message reads, "Kuzu is working on something new! We will no longer be actively supporting KuzuDB. You can access the full archive of KuzuDB here: GitHub" https://github.com/kuzudb/kuzu

I think it just gives you the ability to easily do that with slash command, like using "/brainstorm database schema" or something instead of needing to define what "brainstorm" means each time you want to do it.

Have a look here for a great reference

https://available-anaconda-10d.notion.site/That-Creative-Cod...

Looks like it shows now when the remaining context is < 50%, which is a welcome change to the 15% when it previously would appear.

I would really like for them to add the option to constantly display how much context is left before compression or a new session.

Is SOLID a data format? Or just a server that serves different formats of data through a consistent API? I've glanced through the documentation and I'm not clear on exactly what it's doing that makes it different.

We're living in a reality where nuclear waste was not always properly contained and the repercussions of it are long-lasting. While this particular case is related to the Manhattan Project, it's causing all types of issues to this day:

https://www.wbur.org/onpoint/2025/09/11/long-term-effects-nu...

I visited Auschwitz-Birkenau in February of 1995. It was well below freezing and there was some type of ice ball precipitation, perhaps because it was too cold to snow. I was the only person there.

I walked all the way back from the famous entrance gate, along the train tracks, to the monument at the back. The place was huge and imagining people suffering there during that type of weather was especially heartbreaking. I was luckily able to convince the taxi driver to wait for me. I have some black and white photos I took of it somewhere on my shelves. That visit sticks with me more powerfully than almost anywhere else I've been.

I've tried using this before and pretty quickly migrated away. While I like the idea of it, the default styling is not great and I felt frustrated with the amount of adjustments it needed to support a data-dense site.

Will Clickhouse spill to disk yet when joins are too large for memory?

I'm in an enterprise environment where a central IT platform team controls what size warehouses we can have in Snowflake. They are not receptive to arguments for larger warehouses, unfortunately. Our issue becomes long-running queries b/c Snowflake spills the data to disk during the joins. TBH, I could join the data more quickly on my laptop than in the warehouse I'm allowed to use. Anyhow, I have then an old build server that is beefy & has 512 GB of RAM, so I can set up my aggregation and/or OLAP services there, since it's an unencumbered playground.

Not yet, but it's on the list! This is R&D work that I'm doing on the side, when I have time. Do you prefer StarRocks to Doris?

I loaded this same IMDB dataset into a Kuzu DB the other day, just for fun. It was an interesting project but I would agree that this dataset in particular lends itself to a graph database. Kuzu started to choke with > 10M nodes & 10M edges but I was doing a naive insert & probably could fit the entire dataset in without trouble using their direct CSV import.

We also have a budget issue with Snowflake, so it would help to aggregate elsewhere.

I went down this road with Clickhouse and spent 18 months setting it up for realtime analytics. I'm not sure it's going to stick, primarily because our Data Transformation & Aggregation steps require some gnarly joins across large tables and Clickhouse does not handle large joins well. The consequence is that the aggregation has to happen in a separate system (currently using Snowflake) and when there were changes to what we were processing, it sometimes requires gymnastics both in the aggregation layer and inside of Clickhouse to accommodate the change. Denormalizing was rife with tradeoffs, mostly just to make Clickhouse happy. On top of that, we leaned heavily on projections for performance, which is wonderfully automated, but also meant waiting for unpredictable background processing during backloads, etc.

We might stick with Clickhouse, but after working with it for a year and a half, I'm curious to see whether a system that handles joins more effectively would be a better fit. To that end, my next R&D project is to set up a vertical slice of our analytics on Apache Doris to see how well it handles a similar workload.

I was playing with Aseprite (pixel editor) the other day. You can script it with Lua, so I asked Claude to help me write scripts that would create different procedurally-generated characters each time they were run. They were reproducible with seeds and kind of resembled people, but very far from what I would consider to be high quality. It was a fun little project and easily accessible, though.

- https://www.aseprite.org

Palantir was 90% about ontology creation back when I first used it in 2009. They knew at that point that without some level of structure that mapped to the specific business problem that the data input into the graph was difficult to contextualize.

India seems to be converting to solar without external pressure.

https://www.reuters.com/markets/commodities/indias-solar-boo...

This is technically impressive and I commend the team that brought it to life.

It makes me sad, though. I wish we were pushing AI more to automate non-creative work and not burying the creatives among us in a pile of AI generated content.

Not everything has to be monetized. You will have other ideas or maybe you’ll take this further. It’s a ton of work to build a thriving business, and you may lose some of your joy and pride along the way.

You created a useful tool and have the support of the community! That’s pretty cool. Congrats!

I made a word game while playing with a few ideas, like anonymous usernames and leaderboards. I still poke at some aspects of it. There’s a rare scoring bug I need to isolate and fix. Anyhow, feel free to look. :)

https://www.gorillasuit.io/

Edit: coming up with a reasonable algorithm for scoring is far more difficult than it looks. I guess most of the word games floating around don't have scoring for a reason.

Vendor lock-in is risky and expensive for large corporations and governments, both of which tend to move slowly. I find it completely legitimate that a government would create a tool that's useful to its workforce and helps to avoid vendor lock-in. Insomuch as it's created by the government, it's released as open source.

Most companies and people aren't going to want to maintain the VMs and/or infrastructure to run their own platforms, so they have the option to continue using SaaS offerings like Notion.

Musk and Tesla could have dominated the US EV market for years to come had he stuck with the core clean energy message and not surrounded himself with sycophants and publicly acted like a racist jerk. It’s like a modern retelling of The Emperor’s New Clothes.

I'll second this. Start small. If you think it's small, start smaller. I think a lot of people fail in their quest to learn game development because the scope of their initial ideas are huge.

Edit, I also recommend Designing Games, by Tynan Sylvester (RimWorld creator)

Interesting! Thanks for the link. I suppose the graph databases just take an opinionated approach. NetworkX is great; I always wished it had a simple backend.

I’ve always wondered why there isn’t a “SQLite for graphs,” so to speak. Is there something about how they have to be stored that precludes an in-process solution with disk-based storage?

Regarding scaling… one thing that drives me bonkers about Apache Superset is that the maintainers are absolutely adamant that it must be deployed with kubernetes because it’s meant to scale. The project works just fine with a simple and slim docker/compose deployment, which is easier for small teams to manage. The lead maintainers refuse to document this and have unnecessarily sprinkled the docs with warnings.

IIRC, the Tesla traffic visuals use Godot. The Rivian screens use Unreal Engine.

https://www.unrealengine.com/en-US/spotlights/rivian-brings-...

I love any opportunity to suggest people try out Brogue. It was developed with the idea "What would have happened if development continued on Rogue?"

Info here: https://sites.google.com/site/broguegame/

Repo/downloads here: https://github.com/tmewett/BrogueCE

Applying to and taking a new job requires bidirectional approval and sense of fit. The way a company conducts its interview process is a reflection of the corporate culture and sometimes is enough to erode the sense of fit on the applicant's side. If the interview process is a disorganized mess, why should the applicant believe the rest of the company is any different?