peter_l_downs

For anyone else not familiar with Paul, he is a very effective maintainer of a variety of audio related programs. These are fantastic principles and (as a neutral observer) he lives up to them. Heavy is the head that wears the crown!

You can directly edit the downloaded code when using modules, you don’t need your go.work flow at all. I often do it while debugging particularly weird bugs or to better understand library code I’m using.

I'd never heard of this approach before and I can't think of any downsides. I'll probably start using this with my new work.

I use an iPhone SE (4.7") with slightly larger default text size (accessibility settings) and have the same experience. Everything more or less "works" though, so it's not as bad as it could be --- the visual issues basically just help me spend less time on my phone.

I don't think I've ever seen a website respect my phone's text size, and frankly I didn't know it was posisble, this Airbnb blog post is cool and makes me want to update my own sites.

For anyone wondering, voice/data on Visible's entry-level $25/mo plan is deprioritized in times of congestion, and their $45/mo plan is not. Hotspot usage is throttled on both, differently. You can read the full details on their plans page [0] by pressing the "Get all the details" buttons.

Visible $25/mo:

> Typical 4G LTE & 5G download speeds are 9-149 Mbps. Video streams in SD. In times of traffic, your data may be temporarily slower than other traffic.

> Visible includes mobile hotspot with unlimited data at speeds up to 5 Mbps. Video streams in SD. While more than 1 device may be connected to your Hotspot at one time, a single connected device will experience optimal speeds. Performance will be reduced if multiple devices access data through the Hotspot simultaneously. Actual data speed, availability and coverage will vary based on device capabilities, usage, your location and network availability. Service is not available while roaming.

Visible $45/mo:

> Visible+ gives you unlimited premium data on Verizon’s 5G Ultra Wideband network, the fastest 5G network access we offer — up to 10X faster than median 4G LTE speeds. Premium data means no data slowdowns due to prioritization. Download apps, games, entire playlists and TV series in seconds.

> Visible+ also gives you 50 GB/mo of premium data on Verizon's award-winning 5G & 4G LTE networks when 5G Ultra Wideband is unavailable. Premium data means no data slowdowns due to prioritization.

> Typical 4G LTE & 5G download speeds are 9-149Mbps. Video streams in SD. After 50 GB, in times of traffic, your data may be temporarily slower than other traffic.

[0] https://www.visible.com/plans/

Fwiw I recently started using wouter (https://github.com/molefrog/wouter) and it works great for me, I'm not sure why react-router is so big and has so many other features. I took a look at it but didn't understand it and wouter seems to be working fine for my simple needs (go to different pages, link between them, parse params/)

First: Ilya in particular will be able to raise easily regardless of general market conditions because of his experience and track record.

Second:

> allow me to assist in your understanding of the bigger picture: large funds use VCs as money mules to increase Nvidia GPU sales through investments in AI startups and this is not sustainable.

You have to be trolling (or I'm misunderstanding?) if you're arguing that a large proportion of VC investments are at the direction of LPs who are long NVIDIA, for the sole purpose of furthering that long.

> if large funds are unloading their shares, if executives are cashing out their stock options, who is left to buy the bags?

Literally the buyers purchasing the shares that the large funds and executives are selling.

I'm currently using the ldflags approach [0], but the linked library [1] looks much nicer. I'll probably switch over to it soon. Thanks!

[0]: https://github.com/peterldowns/localias/blob/main/Justfile#L...

[1]: https://github.com/earthboundkid/versioninfo

You should let the Apache Flink team know, they mention exactly-once processing on their home page (under "correctness guarantees") and in their list of features.

[0] https://flink.apache.org/

[1] https://flink.apache.org/what-is-flink/flink-applications/#b...

I strongly recommend picking up a physical copy of The Complete Stories of JG Ballard [0]. Great to read through from time to time. Every story is weird and a little depressing, though, so don't read too many at once.

[0] https://archive.org/details/completestorieso00ball

Makes sense, thank you!

EDIT: degenerate example, but still a good explanation.

As someone who doesn't use webviews, why is this such a necessary feature?

You’ve done a great job communicating the project, in every aspect. Nice work. I’m excited to try this out!

I like this better than livegrep. I haven't actually operated either zoekt OR livegrep before, but I'll probably start with zoekt+neogrok next time I want to stand up a codesearch page. Thanks for building and sharing this!

If you ever leave you can use Livegrep, which was based on code-search work done at Google. I personally don't use it right now but it's great and will probably meet all your needs.

[0] https://github.com/livegrep/livegrep

Interesting, do you know anywhere I can easily read more about this? (I will do my own research, too.)

Surprised not to see Livegrep [0] on the list of options. Very well-engineered technology; the codebase is clean (if a little underdocumented on the architecture side) and you should be able to index your code without much difficulty. Built with Bazel (~meh, but useful if you don't have an existing cpp toolchain all set up) and there are prebuilt containers you can run. Try that first.

By the way, there's a demo running here for the linux kernel, you can try it out and see what you think: https://livegrep.com/search/linux

EDIT: by the way, "code search" is deeply underspecified. Before trying to compare all these different options, you really would benefit from writing down all the different types of queries you think your users will want to ask, including why they want to run that query and what results they'd expect. Building/tuning search is almost as difficult a product problem as it is an engineering problem.

[0] https://github.com/livegrep/livegrep

Most professional cabinetmaker shops are terribly mismanaged and incredibly behind the times. The industry is consolidating as the owners are aging out. Mostly they’re just straight up closing shop because they have no succession plan, terrible workplace habits, and mismanaged finances. The proposed regulation will “harm” this type of shop but any cabinetmaking business that _will_ exist in ~10 years already uses saws with these types of safety features (and equivalently “safe” practices when it comes to things like ventilating their finishing area.)

Cancel your daily meeting and have a single weekly update meeting. Have each project’s lead write down what progress they made last week, risks, problems, wins, and what they’ll expect to do next week.

Spend the first 10m of the meeting silently reading these updates. Then have each lead verbally give a condensed summary of their update (DONT ALLOW them to read verbatim) with a focus on the information that everyone on the team really needs to know, especially problems and blockers. Make sure they do verbally say what their next incremental unit of progress will accomplish and when they expect to have it done.

You can do “people” instead of “projects” for smaller team.

Oh, and keep all the notes and updates in a single shared doc that you add to the top of each week.

Thank you! Just saw this — kind of you to take the time, and I appreciate the compliments.

> Given it's not user facing prod code, I'm assuming high-performance isn't critical, and the nature of what it's doing means using `once.*` is worth the trade-off with concurrency.

I'm impressed you noticed this. I don't do a good job of explaining this in code comments or docstrings, but the linearization / contention is necessary for correctness. Basically, each time someone asks for a new testdb, the code needs to make sure the relevant user exists, and the relevant template exists, and has the migrations run on it. If these things don't exist, the test will need to create them. With many tests running in parallel, they need some way to contend and make sure that the user/template is only created once.

Because golang runs the tests of separate packages as totally separate processes, the code does the contention with "advisory locks" inside the Postgres server. When two tests are contending on these advisory locks, they have to hold a connection open to the server. As a result, server speed and max simultaneous connections are the primary limiters of how many tests can be operating in parallel and how fast your test suite runs.

I added the `once.*` helpers to move the contention "left" where possible, to the memory of the packages that are being tested. Within a package, tests can (and should) also run in parallel. The `once.*` helpers force the different tests to contend in the shared process memory, the theory being that it's faster and that it reduces the number of server queries/connections held open just waiting around on a server-side lock.

I haven't actually tested the code with and without this, and thanks to your comment I will try to do this at some point!

Understood, thank you.

Wow, ok thanks that makes sense — I never thought of an environment like that.

OK, that goal makes sense, thanks for explaining. For what it's worth I'm pretty sure you can do this with postgres, tmpfs, and template databases — see my project, pgtestdb [0]. I haven't done a formal perf measurement, but each test would get a fresh and migrated database in about 20ms on my local machine. The setup described runs postgres in a container for convenience, but you could probably also just run a postgres binary and store the data on a memory-backed filesystem.

[0] https://github.com/peterldowns/pgtestdb

Why would the postgres container need to be nested inside another container? Why not just have the CI environment also run a Postgres container, along side your tests, and give your tests a `POSTGRES_URL` environment variable? Or why even bother running Postgres in a container, why not just run the Postgres binary on the host that's running your tests in the container?

> If your building PG for an embedded, light weight, or under powered system then this would make sense for verification testing before real E2E testing that would be much slower. (a use case I have)

If this is actually just Postgres running in an x86 emulator (*edit: originally this said "compiled to wasm"), then how could this be faster than Postgres in any given environment? I don't understand — if it were faster, wouldn't you just want to deploy this in prod in your weird environment rather than Postgres? Why limit this to mocking?

Can you give a specific / concrete example of why I would want to use this instead of running a postgres server a different way (docker, binary, whatever) and having the tests connect to that server? I really don't understand when this would be useful.

This is very cool, thank you. You should add this to https://github.com/bayandin/awesome-awesomeness

This is pretty cool as background information, but if you've ever run into a situation where you're not sure why something is locking, this kind of theoretical info isn't that helpful. If you want to know what queries to kill, and what's blocked on what, check out these two very helpful Postgresql wiki pages:

- https://wiki.postgresql.org/wiki/Lock_Monitoring

- https://wiki.postgresql.org/wiki/Lock_dependency_information

The "Recursive view of blocking" on the second page has been extremely helpful to me. You don't ever want to need this query but if you do, it's great. You should follow the page's recommendation and set it up as a view you can use if shit ever hits the fan.

...although you may want to show all the locks each pid has acquired, instead of the summary the query gives as written, by modifying it to use

    array_to_string(locks_acquired, E'\n')

instead of

    array_to_string(locks_acquired[1:5] ||
                    CASE WHEN array_upper(locks_acquired,1) > 5
                         THEN '... '||(array_upper(locks_acquired,1) - 5)::text||' more ...'
                    END,
                    E'\n  ')

The people paying $100k are not doing so via government-backed student loans.

"How did this happen?" — because the market will bear it. High sticker price + financial aid for 65% of students just makes it easier for a college to price discriminate, which is overall a good thing. And as the article points out, most students don't pay anywhere near as much as a Vanderbilt full tuition, so in a sense it really doesn't matter. The article does a good job of explaining this.