bchallenor

Interesting. Here is a comparison of the two rules_scala implementations: https://github.com/higherkindness/rules_scala/issues/261

Bazel is a nice build tool, but AFAIK it still doesn't support Scala 2.13, released mid-2019: https://github.com/bazelbuild/rules_scala/issues/809

What does guix mean by "inconclusive"?

I find this pretty fascinating. Apparently it's a single gene that is responsible for the inability to synthesize vitamin C. [1]

[1] https://biology.stackexchange.com/questions/401/why-do-human...

There's a fascinating YouTube series called "The Most Complex International Borders in the World" about enclaves and exclaves. [1] There are even some "counter-enclaves", e.g. a part of the Netherlands inside Belgium inside the Netherlands. [2]

[1] https://youtube.com/watch?v=gtLxZiiuaXs

[2] https://en.wikipedia.org/wiki/Baarle-Nassau

syncthing-lite [1] is already supposed to do what you want for your second point. But it's not really there yet. I haven't managed to get it to work reliably (unlike the original app, which is great).

[1] https://github.com/syncthing/syncthing-lite

On Android I've found that the volume that the phone thinks the AirPods are at can get out of sync with reality, the result being that Android's idea of full volume is actually very quiet. (Perhaps I tried to change the volume before they were fully connected?)

Re-pairing them from scratch fixed this. Might be worth a try.

The customer still ordered via the listing of a specific vendor, even if Amazon shipped from co-mingled stock.

You can just refuel in Earth orbit though. That would use less fuel [1] than landing on the moon unless you were going to the moon anyway.

[1] https://en.m.wikipedia.org/wiki/Delta-v_budget

My example was to give quantitative evidence for the speed of contactless transactions.

It is true that there is no barrier in Berlin, but you still need to buy a ticket. For casual users such as myself, who don't have a season ticket, this takes significantly longer than 480ms: find ticket machine, queue, navigate menu, insert cash, wait for change and ticket to be printed, find ticket validation machine.

It is quite possible to miss the train here by having to queue to buy a ticket, particularly in busy places like the airport. This could be avoided if the tourists were able to use their existing cards/phones to tap in.

Plus, I get an instant notification on my phone whenever my card is used. And if I see anything suspicious, I can freeze the card via the app (declining all further payments).

I am visiting Berlin at the moment, and I miss the convenience and speed of being able to pay with contactless, by card or phone.

Regarding the speed of transactions: cash might be faster than signature or even Chip+PIN, but is surely not faster than contactless.

For example, anyone with a contactless Visa/Mastercard or phone can enter the London Underground by simply tapping at the barrier. They do not need to have a pre-existing relationship with Transport for London, to buy a ticket in advance, or to preload a stored-value card (as you generally must do in other city transport networks). And the ticket barriers open on average in 480ms. [1] That's pretty fast. You can't even pay by cash on a bus in London any more.

[1] https://www.whatdotheyknow.com/request/payment_methods_time_...

Having grown up in the UK, I was amazed when I first saw the Milky Way in New Zealand. I believe it's more visible in the southern hemisphere. [1]

[1] http://darksitefinder.com/how-to-see-the-milky-way/

I make it 4ms [1], not 40ms.

[1] http://www.wolframalpha.com/input/?i=800mi+%2F+speed+of+ligh...

TCP and UDP are "IP protocols" in that their packets are nested directly inside an IP packet and they have associated protocol numbers [1] to distinguish them from other things that might be inside an IP packet. QUIC theoretically deserves to be one of these too but for pragmatic reasons it has to be nested inside UDP. GP is asserting that `-p quic` will not be implemented, because it would be a layering violation.

[1] https://en.wikipedia.org/wiki/List_of_IP_protocol_numbers

I didn't know about the --init flag to docker run, thanks! Looks like that was added last year with 1.13.0. Going to have to try this myself, now.

`terraform state mv` is indeed the trick. It took me a while to understand it, but this blog post helped. [1] It leads you through refactoring some resources into a module.

The key takeaway for me was "we really only need to consider the nodes that map to the physical resources of our infrastructure when we are planning our state surgery. This means we can ignore all of the nodes that correspond to data sources, variables, and providers."

So after a refactor, this is what I do now: (1) run plan to get the names of everything terraform wants to delete and recreate; (2) pair all the resource nodes manually and translate them to state mv commands; (3) re-run plan and verify that terraform is now convinced there is nothing to do.

It would be nice if terraform could do this for me, of course, but I find that it is generally possible to avoid delete and recreate if all I've done is a refactoring.

[1] https://ryaneschinger.com/blog/terraform-state-move/

I use the NFC Yubikey to store a PGP key, which can then be used with pass [1] + GPG on the desktop, and Password Store + OpenKeychain on Android. Works nicely. And if you choose to also keep the PGP key on the desktop, you don't need to carry the Yubikey.

[1] https://www.passwordstore.org

I recently evaluated the two and went with FlatBuffers, largely because its Java support appeared to be more mature.

The FlatBuffers encoding is based on vtables and is relatively straightforward (the runtime library is tiny). This also means it's inefficient for small messages, but in my testing its vtable deduplication worked great for my use case (~100k messages of the same type per memory-mapped file), in that the vtable overhead tends quickly to zero.

Cap'n Proto has a more complex encoding that is probably more efficient in terms of wire size, and particularly for small/standalone messages, but the runtime is larger as a result.

Apparently CodeCommit is a new feature (last couple of months?). I had no idea it existed - thanks!

This paper is very readable - thanks for the link.

Is it possible with scalar subqueries to perform anything other than a tree of correlation? With CROSS APPLY one can correlate a DAG of subqueries, e.g. a diamond where B and C depend on A, and D depends on B and C.

The syntax for this is pretty horrible, however. And if you want to return more than one column from the subquery, you would have to duplicate the subquery definition for each column, right? Then you'd have to have faith that the optimizer can work out what you meant and reconstruct just a single subquery.

No, you can write queries that are not really possible to express without it. Basically, it allows you to execute a table-valued function for each row in an earlier query.

For example, in SQL Server I find a common use of CROSS APPLY (which appears to be the same thing) is where the "table-valued function" is a SELECT with a WHERE clause referencing the earlier query, an ORDER BY, and a TOP (=LIMIT) 1. (In fact, this is exactly the example given in the article.) It allows you to do things like "for each row in table A, join the last row in table B where NaturalKey(A) = NaturalKey(B) and Value1(A) is greater than or equal to Value2(B)".

Thanks for the example. It seems to be the same as MS SQL Server's CROSS APPLY / OUTER APPLY?

Anyway, good that Postgres has it too, now. There are several Postgres features I'd love in SQL Server, like range types...

I don't know about SwiftKey, but the Google English, French and Japanese keyboards all bring up the input method dialog when you long-press space. So these three at least are consistent.

Paris (55,000/sq mi) is twice as dense as New York City (27,778.7/sq mi) (numbers from Wikipedia). It's one of the densest cities in the Western world.

Edit: though I suppose if you consider Manhattan to be "New York" then that is more dense (70,825.6/sq mi) than Paris.

Yes this is close to what I was thinking of. Basically I want a tool for manipulating ad-hoc collections (lists/sets) of data. Something that is as powerful as SQL (but easy to set up for throwaway pipelines), as accessible as Excel (but not as restrictive - Excel forces you to work in two-dimensional projections of your actual data), that interfaces well with standard formats (JSON, CSV, Excel) and data sources (grep, find, REST, SQL, log files).

For example, say I want to make a wiki page to track some kind of code migration project. Currently I might grep for usages of a term, and project out the (module name, term) pairs. I then run this query a few times for different terms, and use Excel to merge and pivot the data so the first column is a module name and the remaining columns mark occurrences of each term. I then copy paste into Vim and use a regex to mangle the data into wiki markup.

There is surely a better way of doing this, using a single tool to glue the steps together so that the pipeline is repeatable and the various steps are individually reusable.

That Subtext screencast is fascinating - thanks for posting the link. Reminds me of the Bret Victor talks.

I agree with your other points - this is something I'd love to build (or see built). But do you think it could displace Excel?

Both the [Leopold Tenkeyless](http://elitekeyboards.com/products.php?sub=leopold,tenkeyles...) and the [Filco Majestouch-2 Tenkeyless](http://www.keyboardco.com/keyboard/usa-filco-ninja-majestouc...) are "full size [except the numpad], heavy, long-key-travel, concave key-tops, easy-typing, standard layout". I have the Filco.