vaughan

Soccer match replays or soccer podcasts or soccer discussions on YouTube.

Any plans for desktop? An Electron replacement would be nice.

Do you use GitHub? Do you work with a team? Did you really review other alternatives and try them out?

Why do they have to take responsibility? I can point to so many oss projects where someone else’s vision was implemented.

Big issue is parent commit hash included in the commit hash. You have to rehash all commits following a history change.

No one chooses to use git. They don’t say: let’s use it because it’s simple. It’s really the only choice because of network effects. It’s one of the biggest glaring monopolies in tech. Think about the barriers to entry of a new vcs. GitHub/gitlab support. Ide support.

I’d love to move away from parent commit hash being included in a commit hash. It makes rewriting history so complex.

Usually problems arise before solutions. I’ve been thinking the same things and welcome this post.

Is taking the Monday or Friday off better?

I’ve always found Monday is a slow day for me to reload everything back into my working memory and get back into flow.

I wonder if this is why Monday meetings are good. So that everyone can be reinvigorated for the week ahead.

Seeing as there are so many tools and no one is using them, it makes me think that they are just too hard to maintain separately from the system itself. Keeping a readme up to date is hard enough.

A good tool needs to be automatically generated from code which makes me think it needs to be integrated in a framework. Or the code needs to be written in a way that is easily visualizable in the first place.

Code comments seem to be the only way to add structure while ensuring the diagrams are kept up to date.

I think there is room for future frameworks that are built with visualization and it’s necessary tooling as a first class priority. When have you ever seen a framework claim it is easy to visualize and understand? Existing software is too much of a mess.

TGV are much worse than ICE. The TGV double-decker sucks. Tiny overhead storage. Bad leg room. Too hot in summer. And toilets are not well maintained. ICE is a much better train configuration. Although the time I used them weekly a few years back they were incredibly unreliable with huge delays.

I always wanted a markdown-like video editor. I want to chop up my videos and make notes about what is in them.

Text based document would be so much easier for this than big clunky Premiere.

Has anyone tried to write a new modern SQLite?

I find looking at example nested json objects for each entity useful containing all the joins. This is how you interact with the data anyway on the frontend. I’ll usually design a db this way.

I was planning on looking into Zaplib, but must admit I am relieved not to have to, because I was hoping `napi-rs` had won this space.

What we need is a TypeScript to native transpiler. I'm sure it will come one day. Rust is great, has a great community and package manager, but I feel it will always be too difficult to use. Rust just doesn't feel like it has sticking power to me. Not as much as TypeScript has at least.

I remember using a gym app with a similar thing 10 yrs ago. I said I would run 7 days a week. Cancelled app after first week. I met my commitment and I never stopped since then.

Discussions…Germany is 10x worse CO2g/kWh than France.

The key is manual curation. Once you need to find a library, you do a bit of Googling/Reditting, and after 30mins you have the full low down on what are the actual alternatives and the differences. All the automated library tools don’t work.

Absurd is really cool. I've always thought it would be great to have an SQL db implemented in native JS though.

With the database running in the same process as your app, you could store native JS Objects of your table rows in the cache, which you could bind events to. So if you modify a row in a table in the db, events could be instantly propagated to the UI. Haven't thought it through fully yet.

SQL is also a bit cumbersome for things like deeply nested data, hierarchies, trees, graphs which a lot of client-side application state ends up being.

Sessions looks cool!

"code/framework overhead" is fine as long as its hidden in a library. Too many people re-implement a data layer client-side that is always a poor mapping to the server data model. My frontend should act as if its running off a local database and sync with the server. It could batch together all requests made to this database that it cannot fulfil or that are stale.

> (I'm not sure if a file should be allowed to belong to multiple tags within the same hierarchy; my gut says no.)

Gmail is a good example. Has very flexible tagging schema. Every tag exists in a hierarchy. Emails can have multiple tags.

SQL is not good for hierarchies though. You need to use recursive CTEs or denormalize relations and things.

My big realization was that the relational model is a constraint on your data so that relational algebra can optimize your queries for perf. But these constraints cause a whole range of issues, which always result in a poorly modeled domain as people try to work around the limits of the optimizer or the expressiveness of SQL.

I've always felt that what we need is a way to maintain a logical schema (E-R diagram / graph schema), and then the physical schema is automatically generated along with denormalizations for perf as necessary. A graph db is simply denormalizing its joins using index-free adjacency.

SQL is simply converted into a logical relation algebra tree. So anything that can do that could be used. It's a shame that PSQL doesn't provide an API for this, then all the quirks of SQL could be fixed. However, then we would probably have a proliferation of non-standard SQL like what happened with JavaScript, and standard tooling couldn't be used.

SQL is somewhat nice because its fairly well standardized.

Try a 3-way M-M join. Or recursive CTE's for hierarchical data. It always looks clean with simple examples. Data these days is much more nested and inter-related.

So you are talking about something like SQLite-as-the-API? I was a big fan of this idea for a while. Difficulties in streaming query updates from SQL dbs and difficulties in working with deeply nested, hierarchical data made me shy away from SQL though.

Having a client-side relational db to work with would remove huge amounts of complexity to most client apps though.

Depends what you mean by developer, but there a heaps of ways to accidentally write code that doesn't use an index, and then you need to understand db internals and how indexing works, and so you are on your way to being a SQL dev. A non-developer I wouldn't expect to understand db internals. You can get quite far though not understanding db internals as a non-dev for simple querying until you write some complex mission-critical query that must continue running, but needs maintenance/starts over-burdening the db/etc.

These contrived examples seem appealing at first, but when you start having deeply relational, nested data, with M-M joins, the relational model is much less appealing. SQL is just one popular declarative approach that people are familiar with and is reasonably easy to read by non-devs for simple things.

Modeling all data on SQL is definitely an improvement on most ad-hoc data manipulations people do.

But say you want to stream updates from your SQL queries, this is something the relational model and SQL dbs are not great at doing efficiently and actually hinder.

I've always felt a more modular SQL database system is needed. SQL dbs are too black box. You can't interact with the query planner. NoSQL essentially is doing just this. SQL dbs have great underlying layers such as storage, caching, transactions, indexing, concurrency, gis support, backups, etc.

If anything, devs probably just need to be more familiar with DB internals and have tools setup to analyze queries easier.

What you need is a versioned mapping layer from the scraped data into your own schema.

The problem is when you need to update your schema to support data/relations not available in your own schema.

The problem with SQL is that schemas are so sticky and hard to change. People are always hesitant to change their schemas because schema changes themselves are difficult and then you have to update a bunch of backend code, and then your frontend code maybe does strange denormalized things, and then everything breaks.

I've been thinking about this for a while, and I think what is needed is a visual tool that can show all dependencies of a data schema element (backend, frontend), so that schema changes are easier to make.

All the layers (db access, api, cache, frontend data stores/caches/frameworks) in modern architectures make it virtually impossible to modify a schema without causing chaos. The solution is keeping the data model and query interface as close as possible throughout the entire stack. For example you should never write any manual data manipulation code (e.e. `people.map(p => p.full_name = p.firstName + p.lastName)` unless this is able to be traced through the entire system. A monorepo, typed ORM, refactoring tooling (e.g. IDE) can help, but its usually never setup well enough or integrates close enough with the db.

I've come to realize the relational model is not a great fit for most data.

It constrains your data model for the purpose of representing your queries in relational calculus, which allows a corresponding relational algebra to operate on them to help optimize disk access. This comes at a cost. Although, if this is your primary goal then that's fine, which it has been for many.

Data these days is deeply nested or document-based, and encoding this in the relational model is incredibly unwieldy, with huge ugly join queries, and the planner starts making random guesses at 6 joins or so.

Everyone ends up with a rigid, and poorly normalized physical schema to suit the sql planner. Think about all the times you avoid M-M joins because your queries will explode in complexity.

Also, pretty much every app these days wants streaming updates to queries. The optimizer doesn't optimize for streaming updates and most streaming is done by polling. Incremental view maintenance is also very difficult to achieve as well as streaming SQL.