dalechyn
/dalechyn19
tail -F thoughts.txt
also started reformatting Casts Actions in "fhub" (prev. hubbie):
looks much better now, protobufs are still weak at getting the input/output params right
looks much better now, protobufs are still weak at getting the input/output params right
After speaking to the great @jxom, refactored what I did previously and finished porting all the protobuf HubRpc API.
Next weekend will figure out how to make parameters prettier and easy way to submit messages!
https://warpcast.com/dalechyn.eth/0x81745858
Next weekend will figure out how to make parameters prettier and easy way to submit messages!
https://warpcast.com/dalechyn.eth/0x81745858
Was able to pull off data from the first time directly from Hub via gRPC!
- Parameters generated from the protobuf are indeed weird.
- Trying out protobuf-es@2 and connect-es@beta that promise better tree shaking, along with beloved viem's architecture.
- Wasn't able to call `getCast`, always returns not found.
I'm quite new to gRPC communications and might be missing some important transport specifics but happy to pull something off!
- Parameters generated from the protobuf are indeed weird.
- Trying out protobuf-es@2 and connect-es@beta that promise better tree shaking, along with beloved viem's architecture.
- Wasn't able to call `getCast`, always returns not found.
I'm quite new to gRPC communications and might be missing some important transport specifics but happy to pull something off!
Added accounts, thinking now of the tranports and clients abstractions.
Also thinking of how to properly split actions to minimally inflate the bundle size https://github.com/farcasterxyz/hub-monorepo/blob/main/packages/hub-web/src/generated/rpc.ts#L406
https://github.com/dalechyn/hubbie
Also thinking of how to properly split actions to minimally inflate the bundle size https://github.com/farcasterxyz/hub-monorepo/blob/main/packages/hub-web/src/generated/rpc.ts#L406
https://github.com/dalechyn/hubbie
Been thinking lately about my full rewrite of farcaster/auth-monorepo.
Thought that maybe a library with a similar approach as viem, but for hubs would make sense?
So that all the other libraries don’t manage the hassle with protobufs etc.
Honestly my hands are just scratching to get another farcaster dev lego.
Thought that maybe a library with a similar approach as viem, but for hubs would make sense?
So that all the other libraries don’t manage the hassle with protobufs etc.
Honestly my hands are just scratching to get another farcaster dev lego.
cast stickers demo <30sec
repo (built with frog & nextjs): https://github.com/dalechyn/farcaster-stickers/tree/main
https://warpcast.com/dalechyn.eth/0x2b3fdccb
repo (built with frog & nextjs): https://github.com/dalechyn/farcaster-stickers/tree/main
https://warpcast.com/dalechyn.eth/0x2b3fdccb
closing the lap whatever it takes
been listening to Rammstein for the last few days.
I was actually learning German for 6 years from the childhood as my grandmother taught German in school and it gave me a huge boost when I grew up and decided that I want/need to know English and was able to learn it effortlessly.
Years passed, I haven't used German in a while and listening to German music brings up the old memories.
I was actually learning German for 6 years from the childhood as my grandmother taught German in school and it gave me a huge boost when I grew up and decided that I want/need to know English and was able to learn it effortlessly.
Years passed, I haven't used German in a while and listening to German music brings up the old memories.
Catching errors in JavaScript is a bummer.
Instead of pyramidal try-catch closures and Effect to fix the whole language to handle errors, the language itself needs a fix.
And apparently there is one.
cc @samuellhuber.eth
https://github.com/arthurfiorette/proposal-safe-assignment-operator
Instead of pyramidal try-catch closures and Effect to fix the whole language to handle errors, the language itself needs a fix.
And apparently there is one.
cc @samuellhuber.eth
https://github.com/arthurfiorette/proposal-safe-assignment-operator
i used youtube for listening to music on desktop since apple music is very laggy.
i found out it interrupts me very much with interesting content i can't stand to not watch.
will be trying spotify instead, if you have any cool playlists for work please share!
i found out it interrupts me very much with interesting content i can't stand to not watch.
will be trying spotify instead, if you have any cool playlists for work please share!
Can’t fall asleep, lots of stuff happened today.
Will put my thoughts here later on this week.
Wish you an easy week, great reader.
Will put my thoughts here later on this week.
Wish you an easy week, great reader.
I somehow started valuing "long.dot.referenced.data" much more than { destructed } = ones when writing React components.
I initially wasn't ok with having "long" variables, but now I adore them for the next reasons:
- you always know where the value originates from, essentially bounding data as a "namespace".
- less chances of breaking type safety
The only intrusive thoughts when you start doing this:
- damn that's too long
It pays quick however. Every time we rename things to make them "look better" and come back to the code we still need to remind ourselves – "where does this come from"?
Imagine a 400-line component with lots of tightly tied business logic and where you destruct all the variables:
- props -> children, className, value etc etc
- `useSomethingCool()` -> something, cool etc
- and it piles up more and more.
vs
- `props.children`, `props.className`, `props.value`
- `somethingCool.something`, `somethingCool.cool`
It's grouped natively, maybe we don't need to "ungroup" it?
I initially wasn't ok with having "long" variables, but now I adore them for the next reasons:
- you always know where the value originates from, essentially bounding data as a "namespace".
- less chances of breaking type safety
The only intrusive thoughts when you start doing this:
- damn that's too long
It pays quick however. Every time we rename things to make them "look better" and come back to the code we still need to remind ourselves – "where does this come from"?
Imagine a 400-line component with lots of tightly tied business logic and where you destruct all the variables:
- props -> children, className, value etc etc
- `useSomethingCool()` -> something, cool etc
- and it piles up more and more.
vs
- `props.children`, `props.className`, `props.value`
- `somethingCool.something`, `somethingCool.cool`
It's grouped natively, maybe we don't need to "ungroup" it?
quite curious if anyone is using https://github.com/dalechyn/fc-auth as an alternative to https://github.com/farcasterxyz/auth-monorepo.
lmk if it's worth adding docs to this or push some effort overall.
working flawlessly for me!
lmk if it's worth adding docs to this or push some effort overall.
working flawlessly for me!
Colors.
That's probably one of the most complex problems for a frontend engineer.
We ain't artists – but we need something to get started with.
I'm a big fan of Radix Colors myself – https://www.radix-ui.com/colors/docs/palette-composition/understanding-the-scale
It offers a range of colors with scales adapted to all UI cases – buttons, hovers, backgrounds etc.
However, I found that colors are quite "default" and often don't meet the expectations of the end product look.
But, I don't know how far ago, this grail has dropped – https://www.radix-ui.com/colors/custom.
It lets you generate the whole scale of colors and they look awesome!
I took the script from their repo and added output of HSL values so they are pluggable in shadcn – https://gist.github.com/dalechyn/2ccaf2a30f75d9dd953b67c9dbbaf64a.
Run with Bun, generate color scales with ease!
That's probably one of the most complex problems for a frontend engineer.
We ain't artists – but we need something to get started with.
I'm a big fan of Radix Colors myself – https://www.radix-ui.com/colors/docs/palette-composition/understanding-the-scale
It offers a range of colors with scales adapted to all UI cases – buttons, hovers, backgrounds etc.
However, I found that colors are quite "default" and often don't meet the expectations of the end product look.
But, I don't know how far ago, this grail has dropped – https://www.radix-ui.com/colors/custom.
It lets you generate the whole scale of colors and they look awesome!
I took the script from their repo and added output of HSL values so they are pluggable in shadcn – https://gist.github.com/dalechyn/2ccaf2a30f75d9dd953b67c9dbbaf64a.
Run with Bun, generate color scales with ease!
not a geekcast but need your vote here
I'm genuinely interested if dark color scheme is overrated.
I personally like light scheme more as with dark scheme the contrast between the background and foreground colors is too high. It's painful to read that for me.
I think we're all used to reading #000 text on #fff bg, but not the inverse.
https://warpcast.com/dalechyn.eth/0xed05a8e4
I'm genuinely interested if dark color scheme is overrated.
I personally like light scheme more as with dark scheme the contrast between the background and foreground colors is too high. It's painful to read that for me.
I think we're all used to reading #000 text on #fff bg, but not the inverse.
https://warpcast.com/dalechyn.eth/0xed05a8e4
Vercel Cold Starts can be easily fixed with Vercel Cron Jobs (lol).
Put vercel.json in the root of the repo:
```
{
"crons": [
{
"path": "/",
"schedule": "*/10 * * * *"
}
]
}
```
This will make Vercel itself fetch the stated page (homepage in this example) every 10 minutes.
Trying this out rn, should keep the pod "warm".
Put vercel.json in the root of the repo:
```
{
"crons": [
{
"path": "/",
"schedule": "*/10 * * * *"
}
]
}
```
This will make Vercel itself fetch the stated page (homepage in this example) every 10 minutes.
Trying this out rn, should keep the pod "warm".
for those who use `drizzle-orm` to store big-big `numeric` values, don't use db.query.
https://github.com/drizzle-team/drizzle-orm/issues/1290#issuecomment-2212049794
this just gave me a 1.5h headache.
https://github.com/drizzle-team/drizzle-orm/issues/1290#issuecomment-2212049794
this just gave me a 1.5h headache.
@awkweb and @jxom's implementation of /frogfm use IIFEs heavily.
if you forgot it, here's a quick reminder: (async (param) => {/*...*/})(1);
it looks a bit doomed at first, but is actually great way to reduce the accessible variables scope.
Use cases:
- A place in code that modifies the end result somehow but needs to infer the type of the previous result;
- Cleaner scope of available variables;
- Having no "intermediate" values;
In Solidity something similar is done to not go over the stack size (without IR compilation), though there you simply wrap your code with brackets to introduce another stack frame that would be destroyed at the end.
Haven't seen that in the wild too as it also looks "weird":
function foo() {
const bar = [];
{
const intermediate = /*long computation*/;
bar.push(intermediate);
}
// you don't have and don't need intermediate here.
return bar;
}
Now I use IIFEs more often!
if you forgot it, here's a quick reminder: (async (param) => {/*...*/})(1);
it looks a bit doomed at first, but is actually great way to reduce the accessible variables scope.
Use cases:
- A place in code that modifies the end result somehow but needs to infer the type of the previous result;
- Cleaner scope of available variables;
- Having no "intermediate" values;
In Solidity something similar is done to not go over the stack size (without IR compilation), though there you simply wrap your code with brackets to introduce another stack frame that would be destroyed at the end.
Haven't seen that in the wild too as it also looks "weird":
function foo() {
const bar = [];
{
const intermediate = /*long computation*/;
bar.push(intermediate);
}
// you don't have and don't need intermediate here.
return bar;
}
Now I use IIFEs more often!
I was a monorepo fan some time ago but switched to multiple monoliths in app development and want to share few tips that help to ease the development.
Why?
My main problem with monorepos was typescript:
When used in monorepos, the common way to manage them is to have a global tsconfig and then to have packages & apps to extend from it.
It is okay and probably the best solution when developing a library/framework, but it's quite a headache when used in Web app development.
Let's say you have a fronend, backend, ui library, some helpers and they are all are split into different packages in a monorepo.
We all love awesome DX, and most of us use drizzle/prisma for code completions and strong typing. Also some use trpc to make use of auto-generated React Query hooks.
That awesome DX comes with a cost – the cost of TypeScript compiling speed.
Why?
My main problem with monorepos was typescript:
When used in monorepos, the common way to manage them is to have a global tsconfig and then to have packages & apps to extend from it.
It is okay and probably the best solution when developing a library/framework, but it's quite a headache when used in Web app development.
Let's say you have a fronend, backend, ui library, some helpers and they are all are split into different packages in a monorepo.
We all love awesome DX, and most of us use drizzle/prisma for code completions and strong typing. Also some use trpc to make use of auto-generated React Query hooks.
That awesome DX comes with a cost – the cost of TypeScript compiling speed.
A kind of deadline you can’t miss.
This setup lets me ship without electricity supply.
Here’s the shutdown schedule rn: 2 hours of guaranteed electricity supply, 2 hours of maybe yes maybe no, 4 hours of no electricity supply, and that goes in circle.
Boosts motivation greatly!
This setup lets me ship without electricity supply.
Here’s the shutdown schedule rn: 2 hours of guaranteed electricity supply, 2 hours of maybe yes maybe no, 4 hours of no electricity supply, and that goes in circle.
Boosts motivation greatly!
Frog & Next.js co-location at the current state *will* slow down your page that has a frame co-located first render, if you followed the exact tutorial here https://frog.fm/platforms/next#bonus-page--frame-co-location and it should be updated.
Next.js docs state the next:
"Next.js will wait for data fetching inside generateMetadata to complete before streaming UI to the client. This guarantees the first part of a streamed response includes <head> tags."
This way if you're generating some regular OG metadata ("og:image", "og:title", etc) this makes it indexable by Robots as they take first response from the stream (if the response is streamed).
However, we know that Frames are usually more UI-heavy than regular "og:image"'s. And since you're co-locating a frame within the page, this would mean that every time the page loads, the co-located frame fetch will delay the TTFB heavily.
If your frame loads ~4 seconds, this will delay the Next.js page render by 4 seconds too!
Continuing in a thread below this cast
Next.js docs state the next:
"Next.js will wait for data fetching inside generateMetadata to complete before streaming UI to the client. This guarantees the first part of a streamed response includes <head> tags."
This way if you're generating some regular OG metadata ("og:image", "og:title", etc) this makes it indexable by Robots as they take first response from the stream (if the response is streamed).
However, we know that Frames are usually more UI-heavy than regular "og:image"'s. And since you're co-locating a frame within the page, this would mean that every time the page loads, the co-located frame fetch will delay the TTFB heavily.
If your frame loads ~4 seconds, this will delay the Next.js page render by 4 seconds too!
Continuing in a thread below this cast