Ms Boba (rebuilding community era)

0 days since last 1 hour spent on a rebase

(but I learned something.... I think...)

i did work more on fujoguide issue 2, i swear, but the cat ate my progress—

(taking care of some pre-existing obligation and then it's time to go heads down 💪)

whats that say under interests. WHAT DOES IT SAY???

I can honk you up with a sexy conference mascot, if you want. Last year's already taken, but I hear that there's a flaming new bachelor in town who may just be up for a meet cutie.

Do server side auth with a secret client (for now) by essential-randomness · Pull Request #6 · ATProtocol-Community/atmosphereconf Putting this here as draft since I was asked for the code

Sure is! Still in progress because I haven't cleaned up the layout components themselves yet, just the server: github.com/ATProtocol-C...

This is specific to @slices.network, if you need more general ATproto (and Astro?) Auth I have another repo that has sample code (though it's not a switch).

My biggest contribution to this site right now has been to move authentication from client to server side. I swear it's to make Astro easier to manage and the code easier to understand and update, not because I'm a pedant (...which, admittedly, I am)

conference profile coming out great

“There’s no single answer that will solve all our future problems. There’s no magic bullet. Instead there are thousands of answers—at least. You can be one of them if you choose to be.”

― Octavia E. Butler, A Few Rules for Predicting the Future: An Essay

I'll use this power responsibly (maybe)

me making the ATmosphereConf website the most beefed up ATproto Astro site out there

BTW late announcement as is tradition but not streaming today cause I fucked up my back and I cannot stand (which is what I usually do). Taking this time to update the progress on FujoGuide and also fix my crossposter so it doesn't take me so long to do it.

The Fujoshi Guide to Web Development – Fully funded on Kickstarter The Fujoshi Guide to Web Development is an upcoming series of instructional zines about coding featuring anthropomorphizations of programming languages and concepts.

Next up, I'll be reorganizing chapter 1. To know when this guide goes on sale (sometimes this year 👀) sign up to be notified 👉 www.fujoweb.dev/volume-0 👈 (page is a WIP) and follow @fujoweb.dev for updates!

I'll keep posting throughout this rearranging as we get ready for beta #2 💪

Scenario Index Version Control in the Cloud This Issue's Scenario: Boba-tan Escapes Disaster! 23 Remotes: Your Code in the Cloud Git'ing Back Our Code! 23 Making Changes: git push Hark, a Typo! 23 Enter the Multiverse: Working with branchEs Dream a Little Bigger, Darling~ 23 Multiverse Collapse: Prepare to merge! The Final Choice... Sort Of. 23 Conflict Resolution: Advanced Merging No Can merge!

Other bits: one big "make sure you've done the prework" upfront (not throughout) for less interruptions, the middle problem I thought I had (convoluted example) was likely a different one (example needs repositioning)... but overall the clone → push → branch → merge → conflicts narrative LANDS! ✨

Let's Rewrite FujoGuide! Issue 2, beta #2 GitHub perches on the top left corner, ready to pounce upon Git, who is very cute and asleep as a catboy loaf at the bottom right corner. A purple git logo is tiled in the background. A checklist: 
 Review Beta #1 feedback (checked) Review Beta #1 flow (checked) Finalize new flow (unchecked) Reorganize intro chapter (unchecked) Plan extra chapters (unchecked)

And so... off to the extra chapter on "multiple remotes" it goes!

I keep going back and forth on whether this issue can reasonably cover e.g. "forking a repo" (which would slot well with "multiple remotes"), but... well, there's a reason "plan extra chapters is unchecked. I'll keep pondering.

An excerpt from the book: This Issue's Scenario: Boba-tan Escapes Disaster! The unthinkable has happened: caught in the crossfire of one of Git and GitHub’s classic skirmishes, Boba-tan’s laptop is now irreparably broken—and just as she was putting the final touches on her NAND Cypher web shrine! (NAND Cypher, charming antagonist of fan-favorite series Binary Calls, and eminent Funblr Sexyman.) Luckily, not all is lost: thanks to Git and GitHub’s combined powers, a slightly-outdated version of Boba-tan’s shrine has been safely uploaded to the cloud. Now it’s time for Boba-tan to download this lost code to Git’s laptop (requisitioned on Terminal’s orders as she waits for her new one), and finish celebrating her favorite fictional character.

For a book like this, "deliver on your promise as soon as humanly possible" means time from first word to cloning the repo and seeing the fun web shrine on your computer must be as short as possible. Plus, if the reader hasn't used GitHub at all, the explanation has nothing to really "latch on" yet.

Version Control in the Cloud 23 Out Toy Project: Boba-tan’s Sexyman Shrine 23 Remotes: Your Code in the Cloud 23 Putting the Hub in Git 23 Cloning: Not Just for Mad Scientists 23 Telling Git What to clone: Addresses on the Web 23 A New Repo Is Born: Using git clone 23 It Starts (and Ends) There: Your Clone’s origin 23 Making Changes: git push 23 Where Were We? Catching up with git status and git log 23 A Quick Refresher: git status After a clone 23 A Deeper Dive into History: git log

Now, I do believe this explanation is a core part of what people miss that ends up making Git/GitHub feel more daunting than it is: it can be explained quickly, simply, and it makes a big difference in whether someone understands or just runs commands.

But it was in the wrong place.

Putting the Hub in Git You may be wondering: if there are multiple copies of my code, how does Git know which one is the “main copy”? Simple but surprising answer: Git has no concept of a single “main copy” of your code! Since each remote repository maintains its own copy of your various commits (change checkpoints), and since commits can be independently copied—or not copied!—between remotes, it may be sometimes be impossible to point to “the most up-to-date copy”. Since changes can be synced independently, each remote might end up having a unique subset of the full code. In the (chaotically maddening) above situation, no remote knows about all changes! While this flexibility allows for cool possibilities in theory, in practice it can make keeping track of changes confusing. So, to make things easier on the brains of poor developers, Git remotes are often used in a “hub” configuration.

When using Git in a hub configuration, a single remote is designated as the one that holds the canonical (or “official”) version of the code. In this setup, remotes send their changes to the central “hub” once they’re ready to be shared. This way, while some remotes may be temporarily out of date, they can always catch up by asking the remote in charge for all the latest changes. In a hub configuration (the most commonly used), a remote is elected as the official copy of the code. All other copies will then send their own changes to it, or download changes made by others. These days, the central hub for most projects is a Git-based web service like GitHub. GitHub and similar platforms store the code of countless projects—small and large!—in the cloud, making it easy to access them, share them, and even collaborate on them. By keeping the main copy of your own repositories on services like these, you ensure your code remains safe and easily accessible—ready to edit from wherever you wish, and share with whoever you wish!

Re-reading it *definitely* confirmed my suspicions. I had already started moving some of the setup from the book into our free learning platform (learn.fujoweb.dev), but there was more to do. One big culprit was spending too much time upfront explaining remotes and the "hub" model.

In the previous issue, we learned that Version Control Systems (like Git) help you track the history of changes made to your files. But that’s not where the power of Git ends! Distributed Version Control Systems—like, once again, Git—allow you to keep a copy of your files on multiple computers, and to synchronize your changes across all the copies.

My favorite book on writing non-fiction (www.usefulbooks.com/learn/forgo-...) stresses to "deliver on your promise as soon as humanly possible", i.e. "drop the reader in the middle of the action and get yourself out of their way".

I knew from feedback/gut feel that this issue did a poor job at it.

Progress report 🚨✨

Slowed down but not deterred by professional hazards* impacting my writing workflow—that is, sitting on the floor surrounded by paper—the first chunk of FujoGuide TODOS are now TODONE! 🎉

Thoughts below 👇

*I sat on an uncomfortable chair too long so now my lower back hates me

I don't know how this ended up being Astromosphere, I swear it wasn't intentional

@essentialrandom.bsky.social is 🔴LIVE on stream.place! AO3.js release + Checking in PRs + Astromosphere Conf Website

🔴 LIVE https://stream.place/essentialrandom.bsky.social AO3.js release + Checking in PRs + Astromosphere Conf Website

Well..... This is really not that hard......

Harkness test but for Linux distros

So, my slashfic between the Ubuntu wheel and the alma Linux hand ring is no good then :(

Alas, I fear you'll have to be cancelled

Harkness test but for Linux distros

Next up, bringing this type of innovative forward thinking to the world of Linux distros

I love that @bmann.ca's summon has resulted in a bunch of fandom folks debating the nuances of incest shipping under an innocent third party's post. Let this be a warning.

(pictured: fujin discuss incest shipping)

By which I meant we should throw clonecest in the middle of it too, just to spice the fight up

"ew, can't believe those dirty incest shippers keep insisting they're siblings. They're clearly CLONES, which is the God-abiding way to ship them"

"You're above even the Browser. I hereby award you the title--"