search

libp2p / blog

Blog site for the libp2p project.
MIT License
9 stars 7 forks source link

src/_blog: Add rust-libpp2p in 2022 post #26

Closed mxinden closed 1 year ago

mxinden commented 1 year ago

End of the year blog post on rust-libp2p, recapping on the many things in 2022. Also useful reflection exercise for the team.

mxinden commented 1 year ago

@p-shahi could you give this post a review?

Steve mentioned that you were working on a general libp2p-in-2022 post. Sorry that I missed that. Any suggestions on how to proceed? I am fine with two separate posts.

mxinden commented 1 year ago

Tried the one-line-per-sentence markdown formatting here to ease reviews and git diffs. Unfortunately this is not properly rendered by our blog, i.e. the blog interprets a single \n as a newline within a paragraph.

Will keep it as is for now. Will reformat before we merge.

(//CC @thomaseizinger for the idea in general and //CC @elenaf9 given that this is exactly the behavior you predicted in our 1on1.)

marten-seemann commented 1 year ago

Does it make sense to have a separate rust-libp2p post here? This would kind of demand a “go-libp2p in 2022” post to be written up as well, and I’m not sure that would be a good use of our time. My preference would be to have a single “libp2p in 2022” post that covers all implementations.

Going forward, I think we’ll be better served by writing blog posts about single topics / features, shortly after we ship those, instead of long summary articles.

mxinden commented 1 year ago

Does it make sense to have a separate rust-libp2p post here? This would kind of demand a “go-libp2p in 2022” post to be written up as well, and I’m not sure that would be a good use of our time.

I don't think this is an all (js, go, rust, nim, ...) or nothing.

My preference would be to have a single “libp2p in 2022” post that covers all implementations.

Not opposed to a general libp2p post. In case someone volunteers to write such post, I am happy to integrate this one into the general one.

Going forward, I think we’ll be better served by writing blog posts about single topics / features, shortly after we ship those, instead of long summary articles.

My mindset thus far was: As long as the signal-to-noise ratio (/quality) is high, the more blog posts, i.e. the more we share about our work, the better.

p-shahi commented 1 year ago

Steve mentioned that you were working on a general libp2p-in-2022 post. Sorry that I missed that. Any suggestions on how to proceed? I am fine with two separate posts.

Yes I'm working on that. I think it's fine to have two separate posts as this article is more detailed and I was presenting highlights

Going forward, I think we’ll be better served by writing blog posts about single topics / features, shortly after we ship those, instead of long summary articles.

My mindset thus far was: As long as the signal-to-noise ratio (/quality) is high, the more blog posts, i.e. the more we share about our work, the better.

These posts are retrospectives of what happened in the last year and so I think they're equally valuable as standalone posts for shipped features

thomaseizinger commented 1 year ago

Tried the one-line-per-sentence markdown formatting here to ease reviews and git diffs. Unfortunately this is not properly rendered by our blog, i.e. the blog interprets a single \n as a newline within a paragraph.

That is a shame. Markdown should not care about single newlines but only start a new paragraph on double newlines ...

mxinden commented 1 year ago

Thanks everyone for the help here.

@p-shahi this is ready to go live. Do you mind merging whenever you see fit?

p-shahi commented 1 year ago

@mxinden will do, I'm waiting for the blog header from the design team.

thomaseizinger commented 1 year ago

Tried the one-line-per-sentence markdown formatting here to ease reviews and git diffs. Unfortunately this is not properly rendered by our blog, i.e. the blog interprets a single \n as a newline within a paragraph.

Will keep it as is for now. Will reformat before we merge.

(//CC @thomaseizinger for the idea in general and //CC @elenaf9 given that this is exactly the behavior you predicted in our 1on1.)

The source for this behaviour seems to be this configuration option: https://github.com/libp2p/blog/blob/4b7f7d7d3ec59202a261781a43bf2382acae71df/src/.vuepress/config.js#L75-L77

I submitted a PR to remove this setting: https://github.com/libp2p/blog/pull/40