86 karma · joined July 10, 2019
I'll have to switch to farming, I swear.
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.
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 ;)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.
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;
}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.
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.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.
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().
Faster by 10% than fastest author implementation on my machine - 19 seconds against 21 for 'threaded_batched'.
Reddit has RSS. Here is an example - http://old.reddit.com/r/all.rss . To subscribe to it, you need to pay 12 dollars per month to Feedly. And this I think is scammy.
This is kind of realistic workload for a web server in data fetching scenario.