Conversation
Notices
-
@cstanhope ipfs is not so complicated conceptually. It's just a ginormous bittorrent swarm with all the files anybody anywhere wants to share, alternatively it's a ginormous amount of swarms, where every directory and file is a magnet link.
Of course that's all a big lie at another level, but maybe it helps? It's bittorrent, directories are a thing and the torrent file is implied.
Then glued on top of that is human-readable naming inside directories, and human-readable naming under /ipns for the top level.
I think the opportunistic dedup, of data and of swarming, between two parties who happen to use the same file content, is one of the real biggise.
-
I self-review my code a lot. I try, and most of the time succeed, to always read git show before I git push.
I often catch things so that git push doesn't happen before I've revised the code, then revised it again.
If it's a chain of commits, I often restructure them -- in what order they come, what goes where, make sure none of them are too big or aren't well enough explained.
Especially if there's a colleague reviewing the code down the line. And ideally, there is.
So I believe I read my code at least twice as much, maybe five times as much, as I write it.
https://hackernoon.com/how-the-godfather-of-cyberpunk-would-write-software-aaaa0f2155c7
-
On Another Social Network I also read my posts a lot. I post, read, update, and read again. The ability to do this allows me to put up the first, rough, post faster. And getting it out there is important when the text lives in a crappy browser. You never know when you're gonna accidentally destroy the text you're writing.
When I post something more than a brainfart on here, I often write it on http://hashify.me. If I fumble and lose the text I know I can find it in my browser history, as hashify.me stores the text, the literal text base64ed, in the URL (!).
And I get two renditions of the text, one in the edit box to the left and one in the preview to the right. This reduces mistake blindness a bit, as the text you're reviewing isn't exactly the same, or at least doesn't look exactly the same visually, as the one you're reviewing. It also makes links clickable (it's markdown), so I can review that they are pointing where I expect them to before I post.
-
> as the text you're reviewing isn't exactly the same, or at least doesn't look exactly the same visually, as the one you're reviewing
... as the one you wrote, obviously. That's what I get for claiming to proofread my texts. I even wrote this one on hashify.me.
I need a pair.
-
@cstanhope Yeah! I use hashify.me to write #HPR show notes. Write markdown on the left, see the live preview on the right, when I'm satisfied, I just mark all the text on the right, "View source of selection", and copy and paste the generated HTML into the show notes form.
hashify.me is an even crazier hack than this though. The original thought was "hey, I can be evil and hijack URL shorteners to store my data", and then there's of course a limit to how long URLs they tolerate.
The built in "generate a bit.ly URL for this" works around it by allowing two levels of shortening.
So for a huge document, you get a bit.ly URL that points to a hashify.me document that is just a bunch of bit.ly URLs, and then it looks them up and expands them. :-D
I didn't write it, but somewhere quite a ways down on my list of things I'd like to do, is rewrite this to use the URL fragment instead of the URL context, so that (1) the server doesn't get all our documents (the server doesn't need it, the client side does all the processing) and (2) it could be hosted on e.g. ipfs.
I learned about it way back when at https://news.ycombinator.com/item?id=2464213 .
-
@cstanhope I saw now that the fragment improvement was even mentioned in the rather short HN comment tree.
-
@cstanhope
biggies*
And of course, as the project progresses, my description becomes ever more a lie -- i.e. there's an interactive aspect now, in the experimental pubsub protocol.