Yeah. I have a poor view of terraform since my first interaction was trying to a few one line changes to avoid repetition but couldn't find why it didn't work without setting up connection to the AWS S3 bucket.
IEA has consistently underestimated solar/wind deployment and cost improvements. Predicting minimal change each year even as prices drop and deployment soars. Should we really expect them to be accurate on the mineral limitations of batteries/solar/wind?
> 1. How you implemented this on the backend? Did you consider using something like Temporal, AWS Simple Workflow, or AWS Step Functions?
Given this already a major change in our client<>server interaction model and that we didn't want to _fully_ rewrite the entire world, we didn't consider additional major changes to our existing backend services strategy (Go services + RPC) as part of this project. We had a bunch of backend logic and common code we wanted to reuse across Flex Link and the legacy endpoints, which gives us a stepwise mechanism for future refactors once the old APIs are turned down.
Once this rolls out to 100%, the new API boundaries do allow us to refactor the backend into something more like you suggest — leveraging step functions, lambdas etc if desired.
> 2. Interested in how you're avoiding (waiting) on network calls on each action. You mentioned it was coming in next post.
Yes! Full details of that would take a dedicated post. However, if you look at the "Client Rendering Loop" diagram in the post ( https://images.ctfassets.net/zucqsg1ttqqy/5kp6LibAllW1YW69jT... ) you'll see there is a "render neighbor panes" loop in the flow. At the point where we've walked the graph and encountered a pane, we can do a quick breadth-first-search to render out neighboring panes (that don't have a processor in between) and serve those all to the SDK. We all them "additional panes". The response includes a map from "action" to "additional pane" so the SDK can know whether to hit the API or use an already-provided additional pane. (this is in the diagram as well)
The nice part is, clients don't _have_ to implement this functionality. They can always hit the server each time they want the next pane. But as a performance optimization they can leverage the additional panes to render many things locally.
> 3. How are you managing multiple workflows? Does a common child graph make sense for a common workflow?
We use the expanded semantic versioning in the post for teams to have their own versioned workflow namespace. On the `workflow/start` call, we have a dispatcher that can pick which workflow to serve based on the provided configuration, SDK version, platform, experiments, etc.
We don't yet support subgraphs for common chunks of a workflow but it is definitely in our roadmap and would allow teams to share common pieces of the graph.
How is session state kept? Is /event required (as data would be sent in /next?).
Also as I understand, Processors won't be involved until they are needed. E.g. if we have 2 panes but only the result of the first was required to be processed, would the processor be invoked after just the first pane was complete?
It's kept as encrypted blobs in redis that times out after some amount of inactivity (to clean up stale sessions)
> Is /event required (as data would be sent in /next?).
Nope! Not necessarily required — although there are some features (client side event tracking, location-in-graph updates on the backend) that benefit from it. We've hooked it up but no feature currently _depends_ on it being called.
> Also as I understand, Processors won't be involved until they are needed. E.g. if we have 2 panes but only the result of the first was required to be processed, would the processor be invoked after just the first pane was complete?
This is true — processors are only invoked as needed. In other words, they are only invoked if the user is traversing an edge that touches a processor. When a processor is invoked depends completely on its location within the graph. The diagram I linked to above in this thread has a stage for "invoke processor" that's only triggered if the backend walks an edge and sees a processor.
There is actually no strict correlation between a pane and a processor. Each can have any pieces of session state they want as input or output. In other words a processor declares "I want Foo ID as my input" not "I want the output of Bar Pane as my input". This helps composability.
The source of this capability is hidden in that you had to pass in a Foo to the call site.
If you had done similarly in the struct example by passing in the function Bar to the caller then you could achieve similar functionality by shoving in a Baz function instead.
Yeah, but that's the thing: in case of dynamic dispatch in OOP, the function is tied to the argument you're passing. In a typical OOP language, your object carries an extra pointer that's hidden from your view - a pointer to a table of pointers to functions, specific for that object's class. Dynamic dispatch goes through that pointer on the object.
Doing what you describe with a struct would require at least keeping explicit function pointers on the structure; the OOP mechanism described above is a generalization of that.
(There are other, neater approach too, allowing late binding dispatched on the types of more than one argument - see e.g. methods in Common Lisp.)
Coverage is pretty good. It is great for traveling abroad as it just works in most countries.
However I'm looking to leave because Google's terrible handling of Hangouts which many used for SMS messaging. Hangouts also allowed phones calls on computers, a feature I will miss.
The thing is, with a painting, the copies can never be the authentic original. Andy Warhol in particular explored this (art as a mechanical process), possibly inadvertently, as well.
With a digital asset there is no such thing as an original. Even the original file isn't original after the OS moves things around or it's loaded into RAM, etc. Does originality matter? Possibly it always was just bragging rights after replication became reasonably accessible and of high quality?
I'm not completely dismissing NFT's conceptually (this is as hyper modern as we've even seen) even though I don't get it entirely (and I DO get crypto). And I'm happy to see a somewhat practical use for crypto and smart contracts here. I feel like we can conceptualize it enough to trick ourselves into something profound.
GP frames it wrong but building codes make make affordable housing very hard to create in ways unrelated to safety.
>most homes built in Des Moines will be required to have a full basement, a single-car garage, and a driveway. Minimum lot sizes for single-family houses will range from 7,500 to 10,000 square feet. Building codes meant to guarantee residents’ safety will now decree their comfort
This conflates zoning with building code. Building codes are things like requiring that your wires be properly attached and connected so that you don't get electrocuted in the shower as your house burns down, or that you have to build enough beams to support the weight of 4 people and all their possessions.
An attack is anything that makes it take less than a brute force effort (of 2^80 operations). A 2^63 effort is really expensive in 2007. But by 2015 computation was maybe 2^5 times cheaper and there was a 2^5 cheaper attack.
I believe that this breakthrough could be quite a bit bigger because it's changing the costs from exponential to polynomial and so speedup is likely a much bigger change.
That’s assuming the 2D representation is representative of near uniform density. In 2D an I-beam and and a solid beam look identical, but they don’t represent the same amount of mass for potential energy minimization.
Play with 3D shapes and you could get identical 2D cross sections to float in arbitrary orientations.
You can but only under very arbitrary situations that aren't common in real life. And if you're assuming it's not hollow and has constant density, then I doubt there's any way to make such an iceberg except if you look at it from one specific angle: looking from the side should give it away. Yet nearly every image of an iceberg seems to show them in that way.
That’s a different question. In practice floating icebergs are often at a local minima not the global minima. They can be at very unstable orientations in calm seas. The constant melting process promotes instability.
