mbell

> Rails has started to show its age amid with the current wave of AI-powered applications. It struggles with LLM text streaming, parallel processing in Ruby

Not at all my experience, actually it was incredibly easy to get this working smoothly with hotwire and no javascript at all (outside the hotwire lib).

We have a Rails app with thousands of users streaming agentic chat interfaces, we've had no issues at all with this aspect of things.

Armchair aerospaceing here, but it feels like he's a whole class of positioning sensors in this analysis. It seems to be you only need GPS and related absolute positioning systems to get you close to the tower. At that point, what you care about is the relative positioning of the tower and the booster. I would think this can be done very accurately with a host of options: cameras, radar, lasers, ILS style systems, etc, etc.

> Sqlalchemy stands out as a library having probably one of the most complete and pragmatic APIs for database access across all languages.

I can't disagree more. Identity map based ORMs are _awful_ to use, in almost every way.

I'm not sure what the current state of things are since I haven't use MySQL recently but this used to be a perfectly valid thing to do.

The issue was that MySQL doesn't use a full int to store enums. If your enum has 8 values, it stores in 1 byte, if it has more than 8, it stores it in 2 bytes. Adding that 9th value thus requires re-writing the entire table. So yes - it can make sense to "reserve space" to avoid a future table re-write.

You also had to be careful to include `ALGORITHM=INPLACE, LOCK=NONE;` in your `ALTER TABLE` statement when changing the enum or it would lock the table and rewrite it.

"If addition doesn't work, I have no way of reasoning about anything in a program."

Hardware addition is filled with edge cases that cause it to not work as expected; I don't see it as that much different from the memory safety edge cases in most programming models. So by corollary is there no way to reason about any program that uses hardware addition?

We used InfluxDB back in the 0.8/0.9 days and it worked really well, scaled nicely with the large number of metrics we were storing.

The switch to a tag based architecture in 1.0 completely broke the database for our use case, it could no longer handle large metric cardinality. Things improved a bit around 1.2, but never got back to something usable for us.

We ultimately moved to using clickhouse for time series data and haven't had to think about it since.

Where is influx at now? Can they handle millions of metrics again? What would bring us back?

I've tried using OpenAPI a few times, it's been...lackluster... I probably won't use it again.

Here are my gripes:

1) For me one of the biggest selling points is client code gen (https://github.com/OpenAPITools/openapi-generator). Basically it sucks, or at least it sucks in enough languages to spoil it. The value prop here is define the API once, code gen the client for Ruby, Python and Scala (or insert your languages here). Often there are a half dozen clients for each language, often they are simply broken (the generated code just straight up doesn't compile). Of the ones that do work, you get random PRs accepted that impose a completely different ideological approach to how the client works. It really seems like any PR is accepted with no overarching guidance.

2) JSONSchema is too limited. We use it for a lot of things, but it just makes some things incredibly hard. This is compounded by the seemingly limitless number of version or drafts of the spec. If your goal is interop, which it probably is if you are using JSON, you have to go our and research what the lower common denominator draft spec JSONSchema support is for the various languages you want to use and limit yourself to that (probably draft 4, or draft 7).

On the pros side:

It does make pretty docs - kinda wish it would just focus on this and in the process not be as strict, I think it would be a better project.

The biggest issue with current attempts at typing in Ruby is the choice of a nominal type system. If there ever was a language that called for structural typing, it's Ruby.

> Our test harness didn't catch it (weird combination of reasons, too long ago for me to remember the details) & it rolled out.

This is why I'm pretty dogmatic about variable comparison in tests.

This is dangerous and stuff like this has caused a lot bugs to slide though in my experience (and maybe ops):

    expect(account1.balance).to eq account2.balance

This is safe and specifc:

    expect(account1.balance).to eq 2500
    expect(account2.balance).to eq 2500

Unfortunately I've run into a lot of folks that take major issue with the later because of 'magic numbers' or some similar argument. In tests I want the values being checked to be be as specific as possible.

(500mi / 6.5mpg) * $5.313 = $408.69

6.5mpg - I just Googled average MPG for a fully loaded Semi, could be wrong.

$5.313 - Most recent highway diesel price (https://www.eia.gov/petroleum/gasdiesel/). I'd expect this is high due to fleet discounts and such.

Client side validation, regardless of the technology used, is a performance and UX optimization.

The backend must always validate and it's this validation that matters for any sort of 'security' or data integrity issue.

> In React 17, React automatically modifies the console methods like console.log() to silence the logs in the second call to lifecycle functions. However, it may cause undesired behavior in certain cases where a workaround can be used.

I feel like when you've gotten to the point that something like this has been proposed and accepted as a good solution to a problem your framework is facing, it may be a good time to stop and reconsider the approach of the framework.

"Any idiot can build a bridge that stands, but it takes an engineer to build a bridge that barely stands."

- Someone

Not with PG. A couple weeks ago I was working on a project that used truncation cleaning, the test suite took 3m40s. I switched it to cleaning with transactions and the the test suite ran in 5.8s.

Truncation cleaning is extremely slow, not only because the cleaning is slower but because you actually have to commit everything your test code does.

Truncating the DB between every test is indeed horrifically slow. However it's much faster to wrap the test in a transaction and roll it back at the end. Transaction based cleaning also allows parallel testing. That mostly leaves the argument of not writing tests that rely on the state of the database being clean. I have mixed feelings on this one.

Just last week I opened a PR to fix some tests that should not have been passing but were due to an issue along these lines. The tests were making assertions about id columns from different tables and despite the code being incorrect the tests were passing because the sequence generators were clean and thus in sync. The order in which the test records were created happened to line up in the right way that an id in one table matched the id in another table.

So, I get the pain. But I'm not yet convinced it's worth a change.

Another option that I think isn't a bad approach is the default testing setup that Rails uses. Every test runs in a transaction but the test database is also initially seeded with a bunch of realistic data (fixtures in Rails lingo). This makes it impossible to write a test that assumes a clean database while also starting every test with a known state.

I would say that pulse-density modulation is more of an abstract concept and sigma-delta is a particular implementation. Or in other words, sigma-delta is a one technique used to produce a pulse-density modulation.

Tablespaces allow you to store tables in defined directories on the file system.

What I was talking about is controlling the ordering of the rows within a table on disk. If you are going to be reading some group of rows together often, ideally you want those rows to be contiguous on disk as a sequential read of a range is much faster than bouncing around to dozens of locations to collect the needed rows. This becomes more important for very large tables. Imagine a 5TB `blocks` table and you need to read 50 blocks to render a given notion doc but those blocks could be scattered all over the the place on disk, it's a lot more work and it thrashes the page cache.

PG doesn't normally make any guarantees about how rows are ordered on disk and it may move rows around when updates are made. It does has a CLUSTER operation, which re-orders rows based on the order of an index you give it, but this is a one time operation and locks the table while running. This makes it functionally useless for large tables that are accessed and updated frequently.

Some other databases do give you control over disk ordering, SQL Server for example has `CLUSTERED INDEX` which you can apply to a table and it'll order data on disk based on the index order, even for new insertions / updates. It does cost a bit more on the write side to manage this, but it can be worth it in some cases.

Notion seems like an interesting data storage problem. The vast majority of the data is in the `block` entity, which are organized into a sort of nested set, written/updated individually (user edits one at a time) but read in ranged chunks (a doc).

Off hand this seems like an almost worst case for PG. Since the updates to blocks could contain large data (causing them to be moved often) and there is one big table; it seems likely that the blocks for a single notion document will end up being non-continuous on disk and thus require a lot of IO/memory trashing to read them back out. PG doesn't have a way to tell it how to organize data on disk so there is no good way around this (CLUSTER doesn't count, it's unusable in most use cases).

Arm chair engineering of course - but my first thought would be to find another storage system for blocks that better fits the use case and leave the rest in PG. This does introduce other problems, but it just feels like storing data like this in PG is a bad fit. Maybe storing an entire doc's worth of block entities in a jsonb column would avoid a lot of this?

That quote is a bit of a cherry pick resulting a wide interpretation that isn't supported.

The actual ruling is something more like "Epic failed to prove that Apple is a monopoly in the market the judge decided is the relevant market: digital mobile gaming transactions".

Here are the relevant sections of the ruling:

> The Court disagrees with both parties’ definition of the relevant market.

> Ultimately, after evaluating the trial evidence, the Court finds that the relevant market here is digital mobile gaming transactions, not gaming generally and not Apple’s own internal operating systems related to the App Store. The mobile gaming market itself is a $100 billion industry. The size of this market explains Epic Games’ motive in bringing this action. Having penetrated all other video game markets, the mobile gaming market was Epic Games’ next target and it views Apple as an impediment.

> Further, the evidence demonstrates that most App Store revenue is generated by mobile gaming apps, not all apps. Thus, defining the market to focus on gaming apps is appropriate. Generally speaking, on a revenue basis, gaming apps account for approximately 70% of all App Store revenues. This 70% of revenue is generated by less than 10% of all App Store consumers. These gaming-app consumers are primarily making in-app purchases which is the focus of Epic Games’ claims. By contrast, over 80% of all consumer accounts generate virtually no revenue, as 80% of all apps on the App Store are free.

> Having defined the relevant market as digital mobile gaming transactions, the Court next evaluated Apple’s conduct in that market. Given the trial record, the Court cannot ultimately conclude that Apple is a monopolist under either federal or state antitrust laws. the trial record, the Court cannot ultimately conclude that Apple is a monopolist under either federal or state antitrust laws. While the Court finds that Apple enjoys considerable market share of over 55% and extraordinarily high profit margins, these factors alone do not show antitrustconduct. Success is not illegal. The final trial record did not include evidence of other critical factors, such as barriers to entry and conduct decreasing output or decreasing innovation in the relevant market. The Court does not find that it is impossible; only that Epic Games failed in its burden to demonstrate Apple is an illegal monopolist. Case Court does not find that it is impossible; only that Epic Games failed in its burden to demonstrate Apple is an illegal monopolist.

> Nonetheless, the trial did show that Apple is engaging in anticompetitive conduct under California’s competition laws. The Court concludes that Apple’s anti-steering provisions hide critical information from consumers and illegally stifle consumer choice. When coupled with Apple’s incipient antitrust violations, these anti-steering provisions are anticompetitive and a nationwide remedy to eliminate those provisions is warranted.

Is there is a solution for using `docker-compose` on mac with podman? I know that podman supports it natively now, and there is `podman-compose`, but I couldn’t find much on getting either working on a mac due to the remote setup.

Regarding Devise + Rails cookie session store:

1. Logging out deletes the cookie, you are really logged out. If your session cookie got stolen, you have other issues but I don't think this is really a matter of being 'logged out'. It is pretty easy to implement 'revoke all sessions for this user' type of logic with Devise and Devise does this of the box when a user changes their password.

2. Permissions are orthagonal to Devise. Devise stores the user ID in the session and loads the user model on every request, any permissions / blocking system would chain from there.

3. I can't think of anything that devise stores in the session where staleness would matter, other than things intended to be checked for staleness, like the salt that is used for the aforementioned revoke all sessions on password change functionality.

That was true of older systems, most newer adaptive cruise control systems I've used have no issue with stop and go traffic.

What I use for https:

    $ ruby -r webrick/https -e "WEBrick::HTTPServer.new(Port: 9001, DocumentRoot: '.', SSLEnable: true, SSLCertName: [%w[CN localhost]]).start"

> I just think that this person just spent hours upon hours of their life working around a quirk in our current society.

I think this is a truism. Much human activity could fall under 'working around a quirk in our current society' at some level or another. Even your dark energy researcher probably spent untold hours greasing the funding gears.

You are talking about string _literals_, there is no motion nor interest I'm aware of in making all strings immutable in Ruby, thankfully.

Sorta - There is translation layer in software but the reason the M1 is so fast at executing x86 code is that it has hardware support for switching to the x86 memory model. This is something no other ARM processor I'm aware of has.

One use case I've used them for is when you have a table that is 'under fire', and you need to add bulk data to it. Doing a large insert into a table like that can cause various issues. Instead I a partitioned table and each bulk load is a separate partition. This allows doing the bulk load to a 'clean' table out of the line of fire. You can then apply indexes, do cache warming or whatever else you may want to do to it, then attach the partition to the parent table to make it 'active'. As long as you have covering constraint on the partition that matches the partition constraint, this results is minimal impact to query performance. We do bulk loads of partitions with ~100-200M rows this way and it's barely noticeable to the query side latency.

I feel like the article misses most of the 'meat' of bulk loading setups. e.g. Using partitioned tables, attaching partitions with little to no locking, indexing after loading, `COPY ... FREEZE`, etc.

One other note:

> Goto solution for bulk loading into PostgreSQL is the native copy command. But one limitation with the copy command is that it requires the CSV file to be placed on the server.

You can use `COPY ... FROM STDIN` and stream the data from the client, this is basically what `/copy` does in psql.

> 13" MBP is a 4GHz part running at 1.4GHz. 16" MBP is a 4.8GHz part throttled to 2.3GHz.

Apple's thermal solutions could be better, but they are designed within Intel's power envelope specs. e.g. The i9-9880H in the current 16" MBP is only rated for 2.3Ghz with all cores active at its 45W TDP. The i9-9880H is a 2.3Ghz @ 45W part that can burst up to 4.8Ghz for short periods, not the other way around.

> The information available around Big Navi (The GPUs expected to launch next month) put them at a +50% performance jump from the last generation and likely able to compete with the Nvidia flagship 3080

I guess it depends on what benchmark you care about but for AMD to compete with a 3080, which is 70-100% faster than a 2080, which is 10-20% faster than AMD's current flagship, they need to do a lot better than +50%.