Transcript: Some notes from curiously Fixing the last few things and shipping a thing So it's officially live grid dot management and that was exhausting Every definition Mostly because When you plan to reset something you keep iterating the thing you plan to reset Then you're not resetting it and When you reset it, oh boy new issues arise all over the place because Because well you've There's a bunch of state and Checks and default values that have forgotten you've set so resetting it creates a bit of a Instant way to see all that secondarily Oh Second as it gets closer to lunch You get all these thoughts Should be a shop this you have this maybe we can squeeze this in and make it work and the answer is You probably care because all of the rest of the process that you Have on a deck is gonna take a while and everything from like creating a new wallet even the wall funding it Making sure to Just update all the contractors. Oh, no, we're switching testing it to main net. Oh my god, we got a Switch a bunch of the IDs network IDs oh, yeah, that's works differently on main net than those tests and to make sure that's fine just No end no, and a bunch of this shit needs to be changed and Then you change it and that bird like breaks another thing and Then you're like will this make sense? This whole the goddamn thing even make sense people so That's there What else Just feels nice to push push go on something and know that the contract is deployed Can't really change it after this And I will probably bite us in the butt in some regard as well Already today. I had a duplicate signature come in and fuck up the adding of pixels it's just uh Yeah Good to test things and also you can't test for everything. But one thing I may think about for next time is baking in the Person for whom the signature is intended To prevent anybody from Losing mint. I'm not sure that would actually benefit anybody just with them at the moment But it is possible I suppose and the other thing is To bake in the exact millisecond time hopefully be duplicate and then maybe Maybe assault In there just for good measure like truly randomize the numbers Prevent any duplicate issues from happening, but no no Also, I'm not planning to break in hundreds of each so it's probably fine As a thing to build on top of over time What else Bunch of little things that you don't think about until the very last moment like the naming on the login privy off handler I'm making sure that all looks good. Luckily, there's two of us. So Cody was Looking out for a bunch of these little visual details. Well, I was going ham on The more heavy algorithm stuff, um, I need a good refactor and I am becoming less averse to refactoring. I think I'm becoming more confident in componentizing things and abstracting away functionality. And this, uh, this stuff used to scare me more, I think, because I just, I had a hard time holding more complex structures in my head. Um, but now that I think that's, it's becoming easier. Um, I can, uh, I can really say, okay, I'm going to take this whole block of code and, and, uh, de-shitify it and make sure that it's actually coherent and understandable. And I feel pretty excited about some of the components that I pulled out of this thing. Um, nothing inherently reusable yet. Um, everything's pretty one and done specific to this thing, but, but it's a, at least it's readable and you can kind of just say, okay, there's some complexity in this thing, but as long as you pass it these three props, it'll figure itself out. I guess what makes a good, good component, really being able to, to sort of draw some demarcations between what is inside of that component and what is not. And, uh, let things kind of go from there. Uh, instead of needing everything to be global state, fucking terrifying. Um, performance, this performance is a rough and it can be a whole lot snappier. But it's going to take time and probably worth just validating whether, whether there's interest in this thing at all or wasting CPU cycles, brain CPU cycles, mostly to save CPU cycles. I guess I've never noticed that trade off before. You, uh, you, um, yeah, yeah. You use brain cycles to save CPU cycles. I guess you could do the reverse. You can use a lot of CPU cycles to save some brain cycles, which is I suppose what I do when I ask GPT to write some code for me. Um, regrets, regrets, um, failures, uh, uh, things I shouldn't have done. Uh, probably get in the habit of resetting the thing more. If you're planning to launch something blank, then you should be comfortable with making it blank right across the building and probably automated because good Lord, there's a lot. You're going in and filtering for specific rows to delete from the database. It should be automated or at least written down in like a long notion file. Um, other regrets, other regrets. Let's see. Uh, okay. Not splitting off into two layers. Uh, although it sounds like a terrible idea, but to prioritize user experience, I think, uh, it would have been good to keep drawing to forecaster in the editor and minting with web three while it connect log, lag me and that's it and not having to talk to each other, know about each other. Um, because the forecaster and wallet connections are handled very specifically within pretty. And we had people, we had one person can get confused. Most people figured it out and went fine, but one person got kind of confused. So avoid that. And frankly, like to reduce the number of possible States where somebody has a forecaster login, but not a wallet. Somebody has a wallet and not a forecaster. Somebody has a wallet and a forecaster. They're not on the right network. Um, to just cut down on the number of possible States. I think, I don't know if this is a regret cause I just didn't really know, but yeah, keep the total number of unique States as low as possible to make it easy to reason about as easy as possible. Otherwise things just tangle and get out of control. Um, learn some interesting things about render loops and passing stuff in as props that aren't actually data, but are signals. And I have kind of a silly way of doing it where I literally just say, if this number is incremented, arbitrary number, it starts at zero every time you refresh the page, but if it's incremented, that is a cancel event from the parent component. But the true state lives inside of the child component. Um, this, this is just a little signal, a little flag to clear it. Never, never used that pattern before. And it's kind of weird, but I guess this is a learning or a discovery. Um, it's, it's stateless in an interesting way because instead of pulling state further up, no, I'm dealing with more movement. It's just a single integer increment. It's a pretty lightweight. What else, um, validate your metadata. It's a pain in the ass, but worth doing before paying dozens of dollars in main net costs because yeah, one word instead of the other. It looks bad. Oh, it's just very disappointing. Um, check the metadata before you deploy. Uh, OpenSea and it's naming for collections is so shitty. Um, as ironic as it is, probably just don't name the thing. The right thing until you deploy, but again, if you fuck something up, you have to deploy it again, which is just annoying as hell, frankly, but, um, yeah, it's like grid 18, um, but it also could be that other projects are named grid. We don't have total control of that. So I don't think we're deployed 18 times. Um, so yeah. Probably another piece of advice, take breaks three hours and start getting diminishing returns past three hours. You really do much as I hate to admit it. Unless the conditions are like just right, just right. And, um, what those are tend to be good sleep, good hydration, edible focus time, no pending appointment in the morning. Um, without those things, pushing an all nighter half an all nighter is just going to mess things up a bit. Oh, what else? Feels annoying to rename something. Feels pretty annoying. Yes. And rename it. Future self will probably thank you for disambiguating. Um, this goes doubly. So if you have some complex States and many States, um, yeah. What else? Oh, that's what that's what that's. Yeah. Kind of it for now. Um, see what, see what happens. Yeah, it goes.
The speaker did not complete their weekly review, which usually provides clarity and insights for the upcoming week. Despite this, they have many projects, personal life commitments, and community efforts to attend to, not to mention taxes. They plan to set week intentions using voice instead of writing, including the exploration of websites for the Diagram Website Explorers Club and developing a Canvas element-based editor for Daily Jam. The technical aspects of this project involve real-time data updates, efficient pixel manipulation, and secure user authentication through tokenization. A function is set to run every five seconds to update the canvas with the latest pixel data, ensuring all viewers see a consistent image while minimizing performance impacts. Other tasks include preparing tax paperwork, organizing Boulder events for systems and AI, and sketching ideas for a project called "co-net." The intention is to spend more time outdoors in the nice weather and to schedule the next "Site Craft Hang," while thinking about potential content for the "Explorers Club" website. Overall, it's a productive Monday morning with good weather contributing to a positive start to the week.
The author is reflecting on the challenges of effectively showcasing their work on the internet, particularly in relation to portfolios and resumes. They express frustration with the limitations of resumes in capturing the depth of their experience and contributions. Additionally, they discuss the ongoing financial and practical challenges of maintaining online projects and the importance of preserving past work for the benefit of future creators. The author considers using archive.org as a potential solution but expresses reservations about outsourcing this responsibility to a non-profit organization. They ultimately prioritize the use of such resources for preserving knowledge that benefits the broader community rather than their own personal or professional work. The speaker is exploring the idea of preserving their work and experiences in a meaningful and sustainable way. They express concerns about relying on external platforms like archive.org and consider alternatives such as hosting their own content and encoding it into a lower fidelity medium. They also discuss the concept of creating their own encapsulation and representation of their work, which they hope will be more long-term sustainable. The text discusses the idea of creating a collaborative storytelling and writing platform that acts as a memory time capsule by archiving and snapshotting links. It addresses the challenge of link rot and suggests that decentralized hosting and a network of machines could potentially help in the future. The text discusses the concept of a scoped IPFS that functions similar to RAID, where each file is known only once but stored multiple times based on its significance. It also touches on the importance of data permanence on the internet, addressing concerns about archiving family photos and trusting companies like iCloud to maintain data indefinitely. The author questions if they should trust these companies and expresses uncertainty about the longevity of their data stored on such platforms.
The authentication approach for a garden project is focused on real-time Canvas grid contributions via WebSocket, using pixels, colors, and ETH addresses. Integration remains within Superbase, avoiding routing through Vercel Edge Functions, by having users sign to verify address ownership and then receive a Superbase JWT token if allow-listed for direct write-access. This system ensures live updates are shared among all users. Separately, standard Web3 modals for wallet connection streamline the minting process, not requiring allow-list checks or additional authentication—merely an ETH transaction and minting with an IPFS hash and signature.