CodeStream Master Plan: addressing the messaging gap for developers with markers(dev.to)
dev.to
CodeStream Master Plan: addressing the messaging gap for developers with markers
https://dev.to/ppezaris/codestream-master-plan-5boh
9 comments
Hi, thanks for building CodeStream, I'm working on a universal celebration platform (LinKedIn for celebration), but is a social value network not a social media network. Basically we don't see end user as a by product so is a different business_logic_$, the project is in stealth mode for now but it will be released shortly, probably 1Q_2019. Long story short we plan to use CodeStream and contribute to CodeStream mission, thanks.
Thanks very much! Let me know if you have any specific feedback about it.
We are in planning stages for a new project, with everyone remote, this looks like a great way to keep the project moving forward and help with code review. Any ETA on VS Code availability?
VS code is available now. Other editors to follow, based on the great work of the LSP project. https://langserver.org
Sounds like a cool concept.
Personally, it's been my (cynical) conclusion that a lot of times the bad-communication around code (e.g. lack of documentation/comments, resistance to PR feedback, closed architecture discussions), when it happens, can be attributed to motivations rather than lack of means.
But perhaps tooling provides more visibility around that and reduces the barrier for edge-cases.
Personally, it's been my (cynical) conclusion that a lot of times the bad-communication around code (e.g. lack of documentation/comments, resistance to PR feedback, closed architecture discussions), when it happens, can be attributed to motivations rather than lack of means.
But perhaps tooling provides more visibility around that and reduces the barrier for edge-cases.
there's one other aspect i've learned from having built and studied communications systems over the last two decades, which is that you shouldn't underestimate how many edge-cases there are when barriers are reduced.
in 2004 nobody shared photos of their lunch with their friends, not because it wasn't possible, but because it wasn't easy. last week i witnessed a teenage girl in a restaurant spend the entirety of a 30-minute dinner taking and sharing selfies. perhaps 100 in total.
it's my sincere hope that a reduction in friction gets us all talking about code more often.
in 2004 nobody shared photos of their lunch with their friends, not because it wasn't possible, but because it wasn't easy. last week i witnessed a teenage girl in a restaurant spend the entirety of a 30-minute dinner taking and sharing selfies. perhaps 100 in total.
it's my sincere hope that a reduction in friction gets us all talking about code more often.
if we do nothing else, i hope we can improve lack of documentation/comments for some people, with one simple enhancement: allow you to ask a question.
currently, all code comments are declarative, requiring you to pay into the system now, not knowing if anyone will ever benefit from your effort.
with question-driven comments, you get answers to exactly those parts of the codebase that aren't clear, as it should be.
well that's the hope anyway.
currently, all code comments are declarative, requiring you to pay into the system now, not knowing if anyone will ever benefit from your effort.
with question-driven comments, you get answers to exactly those parts of the codebase that aren't clear, as it should be.
well that's the hope anyway.
Hi Peter,
You mentioned this "...the ability to talk about any block of code, on any branch, in any state..." Re: "any state." On our team, we'd love the ability to comment on uncommitted changes and share with the team, as it would prevent us from requiring short-lived feature branches. Is that ability available now?
You mentioned this "...the ability to talk about any block of code, on any branch, in any state..." Re: "any state." On our team, we'd love the ability to comment on uncommitted changes and share with the team, as it would prevent us from requiring short-lived feature branches. Is that ability available now?
Yes, absolutely. I made this short video to demonstrate how: https://www.youtube.com/watch?v=D4HCiiQvMuY
I love what you're doing Peter. Which code editors are you planning to support next?
In approximate order: vscode, atom, visual studio, jetbrains (intellij, webstorm, etc), sublime.
We also plan to publish our marker API so that fans of a particular editor will be able to create a client, should they be so motivated.
We also plan to publish our marker API so that fans of a particular editor will be able to create a client, should they be so motivated.
What if I use a text editor and not an IDE?
Which one?
Vim
We do plan to include what support we can in vim, given the limitations of the UI. It's certainly one of our most-requested editors.
Quick question on vim usage. Do you live in your terminal, and fire up vim, edit the file, and quit? Or do you leave your vim process running all the time (or nearly all the time)?
Quick question on vim usage. Do you live in your terminal, and fire up vim, edit the file, and quit? Or do you leave your vim process running all the time (or nearly all the time)?
Hi Peter love what you're doing. Really interested to see where this ends up in a few years.
PS. +1 for Webstorm support
PS. +1 for Webstorm support
Thanks! We implemented codestream with a rather unique 4-tier architecture which we hope will make it easier to port to many editors.
React UI
Editor extension (initiates webview)
LSP agent
——cloud or on prem——
API/mongo
Hopefully this means most of the work happens in the three layers that are common across editors, and only the extension code needs to be ported.
React UI
Editor extension (initiates webview)
LSP agent
——cloud or on prem——
API/mongo
Hopefully this means most of the work happens in the three layers that are common across editors, and only the extension code needs to be ported.
Understanding code is one of the hardest problems in software development. At CodeStream, we think we have a novel approach to address this by first making it easier for developers to talk about code, and then capturing those code-based conversations and homing them where they belong -- with the code.
How we deliver the first phase of this functionality, and why we think it’s important, is outlined in the link above.
[sorry if you saw this yesterday; I had a glitch in posting it the first time]