So, rather than proxying requests from some server, I can use their dynamic ip product to just auto-update the DNS entry for my home computers whenever my ISP changes my DNS.
I imagine there will be some small downtime every time my ISP switches (cached DNS / TTL etc...), but it should happen rarely ().
I'll also search for "dynamic DNS" and see if anything else comes up, but this looks like a really good solution, thanks for posting it.
> This is a lot like the programmer tendency to want to re-write instead of refactor because to understand a system is way harder than to set out on a quest to build a new one.
And what if they did want to refactor the existing system. Can they? What does that iteration process look like? Is the system currently evolving to fit everyone’s needs?
Remember, RMS actually did want to refactor the printer. He just wasn’t allowed to. [0]
Contrast that with how fast things are moving in DeFi. It’s permissionless innovation at its best and worst. We can barely even wrap our heads around OHM, but nobody needs permission to fork it into SPELL. Systemic refactors happen faster. [1]
When somebody in the future doesn’t like a piece of decentralized infrastructure, they can _literally_ fork all of it and just make their change. With fewer black-boxes, we share more intellectual property.
I think the Helium project is a fascinating experiment, and I’ve had a lot of fun participating in it. I’ve been tracking my experience for a while (with pictures): [0]
It’s certainly a weird project, and watching the corporation contort itself into something coordinated enough to drive partnerships like this but decentralized enough to qualify as a cryptocurrency is a sight to behold.
The governance of this project isn’t “decentralized” in any strict sense of the word, but the separation of the dewi alliance from the main corporate entity is interesting.
The self-imposed technical constraints are equally fun to observe. The scaling issues (gossiping blockchain data across 100k+ raspberry pi devices with no broker) are insane, and the incentive mechanism for “validators” is an interesting incremental solution. Specifically, people ”stake” $200k on cheap cloud servers, which might earn money for a few hrs a week when elected to a “consensus group.” This made sense historically (on distributed raspberry pi devices) but is now really strange compared to most other blockchains where validators earn consistently.
Every one of these issues is a bottomless pit of learning opportunities as worlds collide (economics, telecom incentives, cryptocurrency price swings, hobbyist antennas, etc…).
I’m no maximalist (I’ve sold lots of coins), but there is something deeply fun about watching _anybody_ try to do something novel to compete against the old guard. That’s why I was up at 6am today to fiddle with an antenna on a friend’s roof.
It seems like a great way to make some of the industry-standard info more approachable to newcomers. I spend a lot of time explaining to people how TC works at tech companies, and IMO employees win when that info is more palatable.
I guess it’s still hard to do an apples-to-apples comparison unless all your job offers look like this, though.
I quit my startup & picked up a boring, stable job to be a better dad a couple years ago, so I feel this too.
If the article said it’s only hard for moms, then I’d disagree with it... but it doesn’t.
It’s just critiquing the assumption that every mom wants the same thing. These assumptions form social pressures & impact career decisions, and she’s pointing out that you don’t have to struggle with that decision in the way society expects.
Sure, it would have been nice if they acknowledged dads... but given the name of the website, I don’t think we’re the stars of this show, and that’s fine.
I loved reading serverless-stack a couple of years ago; it was really helpful & convinced me to use serverless for a side-project that’s still going (with almost no expenses!).
I’m surprised to hear how many separate lambda functions each service in your example had. I understand the need to deploy each service independently... but to have +10 deployments within each service seems crazy to me. Is there a reason each service needs so many lambdas (vs deploying the service code as a single lambda function with different branches)?
Fwiw, I found it possible to get quite far with a single monolithic lambda function that defined multiple “routes” within it, similar to how an Express server would define routes & middleware.
Anyways, thanks for writing that PDF, and good luck with Seed!
Thank you so much for this comment. I can’t believe I didn’t know this, I’ve been inverting my colors & sometimes wearing cheap, non-polarized sunglasses at night — no more!
I had to fiddle with the settings quite a bit to get a 1x zoom w/ the filter, though.