roman-holovin

Both Samsung and Google already did it. My S26 Ultra supports Airdrop and I've tested it by sending and receiving photos with iPad

This whole thread is trainwreck. Your initial comment is three simple sentences with very little room for misunderstanding yet here we are. Then there is a comment on that comment which is self-promotion of LLM-trash published as blog post. One would think should an easy donwvote, but it is not. Then, a dude who pointed out this lame self-promotion is donwvoted into oblivion, because what? Bunch of people cannot think of three seconds and use their eyes to try to understand what's lame about that?

I'll have to switch to farming, I swear.

I read it as in 380 packets per whole call, which was a minute long, not 380 packets per second during 1 minute.

Performance tab in Chrome is miles better than in Firefox.

Debugging is huge part of this. For example, for web where you can plop breakpoint or print statement anywhere and have a good level of transparency into what is happening really helps resolve issues quickly.

Game development where GPU is not really going spill the beans of what is happening under the hood that easily - one can stuck for a longer times easily.

Nope, mine on linux doesn't auto-update itself, though I update it diligently, but manually

This is one reason I'm not really into utility frameworks. They are able to deal with "appearance" part of the CSS just fine, but layout part is too rigid and inflexible.

You can use plain old CSS for layout purposes and mix it with utility classes for appearance.

You can do:

    <div class="actions">
        <button class="h-10 px-6 font-semibold rounded-md bg-black text-white" type="submit">
          Buy now
        </button>
        <button class="h-10 px-6 font-semibold rounded-md border border-gray-200 text-gray-900" type="button">
          Add to bag
        </button>
      </div>

And then:

    .actions {
        display: flex;
        justify-content: flex-end;
        align-items: center;
    }

    .actions > * + * {
        margin-left: 16px; // or better use var from tailwind to set sizes consistently.
        @apply: ml-5; // or do this https://tailwindcss.com/docs/reusing-styles#extracting-classes-with-apply
    }

This should combine those techniques, but I haven't used it in practice. And I'm sure in this case you will be labeled as heretic by both people who don't use utility frameworks and those who do ;)

I don't think it is fair to blame the tool for the mistakes of the operator. I feel like the real issue is that demand for software developers and specifically web developers is higher than than supply. Which leads to a situation where anyone who can put pixels on the screen, with at least some degree of reliability, will be hired and will put pixels on the screen. And they will choose whatever tool there is.

Another issue is that if look through job postings carefully, you will see the pattern there where framework knoweledge is valued above everything else. It is "React Frontend Developer" or "Vue Frontend Developer", not just "Frontend developer who is capable to pickup whatever technology we use".

There are reasons for that, of course, but it is hard not to see that this approach will likely skew hiring into looking for a specific knowledge in candidates. And candidates are going along with a path of the least resistance and learning stuff they need to work with backwards.

That's very reductionist approach. Sure, margin is a sharp tool and you need to use it responsibly.

I avoid putting margins on "first"-level selector.

So instead of

    .button {
      margin-left: 16px
    }

I do

    .parent > .button {
      margin-left: 16px
    }

Difference is that I can reuse '.button' elsewhere without modifications.

Another point to consider is that margin is not the only CSS property that affects layout. Both grid, flexbox and 'position' properties should be used with same care. And approach I highlighted above is usually good enough.

For margin specifically there is also a "owl" selector that makes is a bit easier to manage

    .parent > * + * {
      margin-top: 16px; // OR
      margin-left: 16px;
    }

Just wait for an update that will reenable everything you've disabled.

>developing components in isolation

Nice "isolation" they have when they bundle in whole corejs into component view.

My component was parsing a lot of dates from RFC3339 string via `new Date` and it was mind-blowlingly slow. I opened dev tools and was greeted with javascript re-implemenation of the Date constructor in all glory.

Suffice to say that I had zero intentions to ship that into production bundle. Thanks Storybook, isolated playground indeed.

I feel that problem is that some CSS has to be tied to markup and some of it - doesn't.

There is bunch of CSS features and techniques that work only when you enforce certain parent-child relationships of the CSS rules.

Simplest example of it is 'position:absolute' that requires some parent node to have 'position: relative' to be useful. But there is more to that, both flexbox and grid require certain properties to applied to both parent and children nodes at the same time.

Nesting is one way to enforce those relationships and make sure that they are co-located in the stylesheet code.

Something like that is, in my view, good usage of the nesting:

   .parent {
       display: flex;

       & > .child {
          flex: 1 1 auto;
       }
   }

   .child {
       color: red
   }

I specifically added an example that changes color for class `child` and I think this should not be included in the nested rule because this part of the styling is not affected by a parent in any meaningful way.

I have used pragmas from the article.

Since it is only 100M rows, it takes 1.8 GB on the disk, so I've used tmpfs for this which essentially is a ramdisk. But I have a gen4 pcie nvme SSD - it can reliably write at 4GB/s sequentially, so writing takes a ~500ms for 100M rows, it is not a bottleneck here. random() takes ~half of the insert time. Generating those values with Rust, for example, is faster, but sharing this data with sqlite takes more time than generating it with random().

Maybe implementing custom virtual table in C or Rust like build-in generate_series, but the one that will produce user table fields will be faster, but that is significantly more effort than my query.

This query with random() and generate_series executed in sqlite CLI takes whooping 8MB of the RAM, so you don't even have to close all Electron-based applications to run it on a computer with 8GB of RAM.

Well, even if you just insert zeros instead of random values, it takes 9 seconds on my computer to insert 100M rows, so even that is not a 1B rows per minute.

And I think INSERT INTO ... SELECT is the fastest way to bulk insert data into sqlite.

Also, I have tried to use carray sqlite feature that allow to share memory with sqlite and use recursive CTE to query it, but it is slower. Though, you can pass values you've generated from Rust instead of using random().

INSERT INTO user (area, age, active) SELECT abs(random()) % 1000000, (abs(random()) % 3 + 1) * 5, abs(random()) % 2 FROM generate_series(1, 100000000, 1)

Faster by 10% than fastest author implementation on my machine - 19 seconds against 21 for 'threaded_batched'.