Coming to the site from an aggregator (and needing to be convinced to use Ash, rather than coming there directly and already knowing I want to use ash) I found the book a little weird to be so front and center.
I would have really hoped for a small code snippet or screenshot showing how powerful the framework was. And a book a little further down from that would be nice. But "pay to learn" before "here's a quick snippet on why ash is neat" would have made me more excited for this thing I hadn't heard of before, and who's website I was visiting to learn about.
---
Seeing a book first gave me a different impression -- like one of the old snooty languages/tools from twenty years ago that was really enterprise-only.
I can tell that's not the vibe Ash is aiming for, but it's what I picked up!
(Somehow, I also couldn't find the documentation link on the first two tries. But that's also my eyes being weird and missing the sticky header where it clearly says Documentation!)
I'm really enjoying the discussion on how shuffle means different things to different people (I personally prefer random, but implementing `shuffle` specifically sounds fun with all of this)
> You insert each item into a random position among the remaining items
Thinking about shuffle + adding, I would have thought "even if it's added to a past position", e.g.
`5 4 6 21 3` as valid.
What do folks expect out of shuffle when it reaches the end? A new shuffle, or repeat with the same permutation?
I think all of this depends on the UI presentation, but when “shuffle” is used, I think a good starting point is “what would a person expect from a deck of cards”, since that’s where the metaphor started.
I don’t think that provides a totally clear answer to “what happens at the end”, but for me it’d lean me towards “a new shuffle”, because for me most of the time a shuffled deck of cards draws its last card, the deck will be shuffled again before drawing new cards.
The airports I fly at (student rotary pilot) have all had the same traffic for rotary/fixed wing, but the FAA talks about [flying _opposite_ planes at a different altitude](https://www.faa.gov/air_traffic/publications/atpubs/aim_html...) as a potential practice.
My understanding of why (and also why we're cleared _direct_ a lot of times) is that we move a lot slower than planes, and that ends up being dangerous in its own right in a pattern shared with planes!
I imagine in that scenario the engineering team can develop inter-dimensional travel, then travel to a universe in which that command was never executed. They bring the data back and restore the database.
I managed to delete all records in a table a week ago ( I blame copilot ). Used time travel ( not quite inter-dimensional travel ) in bigquery to restore. INSERT INTO ... SELECT *
FROM ... FOR SYSTEM_TIME AS OF TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 1 HOUR)
Your bet is correct! These are considered `reports`. The default `task` view is called `next` (what are my next tasks), but there's plenty of others, plenty customization (sort order, filters, columns), for those built-in reports, and custom reports as well [1]
I used a stacking review system at two other roles (gerrit and phabriactor). At the time I found it annoying and missed the pretty Github UI and the ability to bunch commits together.
Now that I'm using Github full time, I miss the stack. I found stacks allowed me to easily commit for a few problems at once without bogging down a reviewer.
It sounds like you're already a fan of PRs being small, and that probably means _doing one thing_.
What about a spelling mistake in a nearby but unrelated comment? That probably should be a separate PR. In the stack-world, I was happy to make a second commit, create a second review artifact, and be OK with it shipping eventually when the other features of my commit ship (especially if they're close enough to cause a merge conflict!)
Today, I have to:
* Stash/commit -m temp my current work
* Checkout a new branch, make the fix, push it up, make a PR, etc.
* Check back out my old work, potentially rebase on top of it if it's going to cause a merge conflict
* get back to work on the real issue
* Create a PR for the real issue... and hopefully not have it reviewed until the doc fix is already merged, because it's going to show up as an unrelated change here anyway!
There's also merge-into-other-branches that might help with this workflow, but I haven't found anything graceful yet.
In practice, I avoid the documentation fix to avoid the change in flow, when I'd have been happy to just have it as a different commit in the stack.
--
that covers more generically why I like stacks, I'm not sure graphite would solve my problems after reading the OP though.
I have used ghstack for exactly the problem you describe, but I like how graphite managed trees of stacks, which is better than ghstack‘s linear stacks
I thought that was a really interesting stat (I believed you, I don't mean I went to fact-check you but that's what ended up happening!) and wanted to read more about it -- it sounds like dryer fires aren't _overall_ that destructive, but in the "washer & dryer" category (~16k fires out of ~350k per year) they are 92% of that category.
Figured you'd want to know, since I found it interesting!
That being said, the dryer fires are certainly preventable and if any technology aids in reducing that, it's well worth it!
I have my amd framework hooked up to a Lenovo 27" monitor over USB c and that daisy chained to another of the same monitor type over display link and it works like a champ: USB, video, Ethernet, and power all through the one cable.
Though it did NOT work out of the box to a display link USB A dock. I think it needs display link kernel module and I didn't want to bother.
I think a good example for your hypothetical would be the sinking of a nuclear plant propelled ship. If country B invades the territorial waters of country A with a nuclear destroyer and country A destroys it, the fallout (morally and chemically) would still be on the aggressor for creating the situation where it's reasonable to expect their harmful payload would be destroyed.
I'm imagining something far less obviously threatening (balloon rather than a destroyer) and far less explicitly damaging (maybe a liquid or gas that would mix with the missile impact, and rain down barely noticeable granular substance that, oops, contaminates farm land).
I can appreciate this is quite far fetched given that the material would need to drop such a distance rather than completely disperse with wind, and not be super obvious about it (e.g., pellets).
thanks for taking this on!
reply