emadda

You can do that with many proxy GUIs like Charles. I think the feature is called Map Remote.

ngrok -> gui proxy -> your dev server

That's a nice mental model for promises.

But it is not always true that one promise instance can be awaited in multiple places.

In Swift you cannot get the ref to the Promise instance, so you cannot store it or await it at multiple places.

Once you start an async fn the compiler forces you to await it where it was started (you can use `await task.value`, but that is a getter fn that creates a new hidden promise ref on every call).

I did guess it might be harder to do than vanilla SQLite, as vanilla SQLite just has the WAL and main db on the same hard drive, so it has more space to grow the WAL and it is not an issue when the machine/instance reboots (as it just starts where it left off, even if the WAL is large and has not been check-pointed back to the main db).

To be honest this is an edge case. But I often start a read transaction on a SQLite connection just so I know multiple queries are reading from the same state (and to ensure state has not been changed between queries).

E.g. if you have many websocket connections and they each have a snapshot at a point in time (that spans over many different await function calls/ws messages).

SQLite can have many readers and a single writer with WAL, so a many read transactions can exist whilst the writers move the db state forward.

Some other interesting points:

- The write api is sync, but it has a hidden async await: when you do your next output with a response, if the write fails the runtime will replace the response with a http failure. This allows the runtime to auto-batch writes and optimistically assume they will succeed, without the user explicitly handling the errors or awaits.

- There are no read transactions, which would be useful to get a pointer to a snapshot at a point in time.

- Each runtime instance is limited to 128mb RAM.

- Websockets can hibernate and you do not have to pay for the time they are sleeping. This allows your clients to remain connected even when the DO is sleeping.

- They have a kind of auto RPC ability where you can talk to other DOs or workers as if they are normal JS calls, but they can actually be calling another data center. The runtime handles the serialisation and parsing.

The pricing on some services can also be surprising.

A cloud load balancer is $20/month before you even handle traffic.

I think they are introducing a $1.50 charge for every uptime check, when they were initially free.

You could also use the "share" menu and airdrop the audio from your iphone to your mac. Files end up in Downloads by default.

Do you have an email? I am thinking of doing a blog post comparing css/auto layout, and would like your input?

Yeh, I edited my reply, I realised what you meant afterwards.

Auto layout does sound neat.

You can also use `minmax(min-content, max-content)` for the center col: (https://jsfiddle.net/y193p2b6/).

But this does not keep the center col exactly centered, but it does allow the content to take the free white space and then wrap when needed.

In your original post with Swift, what happens?

I am not familiar with auto layout so I do not know the exact behaviour vs CSS. Do you have a few screen shots of how it would handle different sized content?

I see.

https://jsfiddle.net/Lah5g3vb/

Changes:

- each col is now 1fr (3 cols, 33% each)

- the child elements align inside the col using `justify-self: start | center | end`

I am just saying the columns of the grid can be dynamically sized depending on their contents.

Tracks is a grid term for rows or columns, as it works in both dimensions.

Grid allows minmax(a, b) to specify the bounds of tracks. Possible values can be the remaining free space in the parent (fr), or the size of the content in the child.

There is also fit-content:

E.g: grid-template-columns: fit-content(150px) …

.parent { display: grid; grid-template-columns: 50px 200px 80px; justify-content: space-between; align-items: center; }

An interesting thing you can do with grid is align the tracks.

I wrote about this here:

https://cssprinciples.com/3/grid/#justify-and-align

I recently released https://robata.app. It provides a view of all your windows, allowing you to select the one you want. It's slightly different from Alt-Tab, but you might find it useful. I've also added Alt-Tab-like shortcuts in the next version to be released.

Respectfully, my experience says otherwise:

https://jsben.ch/cSWJa

- JS object appears to be at least 2x faster than document.createElement() (Chrome)

- Note: JS object only loosely represents JSX element so it is a bit unfair. But with actual JSX objects I would assume it is still somewhat faster than the DOM API.

https://youtu.be/DgVS-zXgMTk&t=1532

- Pete Hunt, one of the React devs, says "JSX is faster than the DOM because it is JS memory."

One of the reasons for JSX originally was to reduce usage of the DOM APIs, as they are slower than direct JS object manipulation. The JSX diff of prev/next allows you to minimize DOM API calls.

I would guess there is more overhead in creating a dom element than a JS object (which JSX elements compile to).

I mean gaps of white space that are part of the design and could possibly host content for different app states (not uniformly distributed between flex items).

One thing flex cannot do well is white space: how do you leave a gap of content without spacer divs?

This becomes more complicated when the number of divs is dynamic as flex determines position based on siblings. With grid you already have defined the “layout”, and you are just placing the div into the correct position.

Grid does that in both axis too. So although you may be able to kind of replicate the 1d version with flex, it becomes much harder to align in 2D.

I wrote an article about this: https://cssprinciples.com/3/grid/

I think two reasons:

Caffeine is not the only stimulant in coffee. It’s just the most well known.

Some decaf coffee is more like “reduced caffeine”, not “no caffeine”.

Will the MOR feature be merged into regular Stripe, or will they remain separate?

Two features that may help in bigwav:

1) You can add more timestamps by adding paragraphs with enter.

2) You can playback at any word by highlighting it and pressing space. You can also cut with right click on the wav ui.

Thanks for the feedback! Maybe I should add a "download as .txt".

What do you typically do with the text on export? E.g. Do you parse the times?

Or also a permission to disable automatic updates to reduce the issue of “popular extension sold to malware corp”.

Nice, are there plans to notarize the mac app?

I built something similar here: https://bigwav.app

I learnt how to use tables for layout from Google's homepage design.

I think in general interaction between generator tools and hand written code is very difficult.

Once you start with one you cannot then use the other on the same code.

Nice tool. I feel generators are good learning tools, but once you grasp the syntax and features you gain more flexibility and are able to connect code to a concrete visual in your mind.

The chrome dev tools are also useful as it allows you to modify a grid in place to instantly see your changes.

I wrote a post on grid here:

https://cssprinciples.com/3/grid/

Why the Creatine? What does the Glycine do?

I think the reason channels become harder to understand is that you jump to having a network topology of senders and receivers to reason about.

With async/await, everything is still a function. Your IDE and debugger help you understand when and where a function is called. When debug-breaking on a function you have the stack trace.

Async/await gets you fast context switching for IO ops as it is a single OS process (no threads for the OS to constantly switch).

But once you go beyond a single OS process, then you need something like messaging or shared memory on top of async/await to communicate between OS processes/threads.

I think Golang jumps straight to messaging which is better for multiple cores, but misses the first step of async/await which is easier to reason about when you have a single process on a single core.

One minute compiling Swift UI code - is that without the worst case line above?

So every edit you need to take a minute to see how it renders?