Issue Number One: How To Begin... about pairhub

[TimMikeladze]

I think a good starting place would be to figure out what functionality you want to have and write a graphql schema for it. The process of writing the schema will flesh out more specifics.

[gustavlrsn]

Closing this issue here as a bit of a clean up, thanks for all the feedback and encouragement. Things are finally happening again. Hoping to deploy what's currently in the repo as soon as possible, see #3 :).

[gustavlrsn]

Hello @langpavel! Nice to have you here and thank you for opening the first issue 🙂.

My core ideas so far in terms of the platform include:

• GitHub login and usernames, and public profile page (possibly some sort of reputation system)
• A project/groups structure (join/create groups around open source projects, technologies, courses, your own ideas etc, to solve what should we pair program on, and who shall I pair program with)

Some other ideas I've thought about:

• Guide/introduction to how to pair program, and other features to help people over initial hurdles
• Scheduling helper (w. regards to availability and timezones)

The overall mission is to make pair programming much more accessible.

Also, in terms of the tech stack, as you can see I started out with Meteor for this project, but just when I was starting to relate the data structures to each other I had to reconsider. As the data in this project will be very relational with users and groups (many-to-many), posts, comments and sessions et cetera, I think Meteor with it's pub/sub with mongodb isn't the ideal choice. I think GraphQL would be a better choice. And if you take out Meteor's pub/sub system I don't think there is much reason to still keep Meteor around, it would only serve to limit the possible numbers of contributors as well as future maintainability.

So, a new tech stack would be something like GraphQL, React, Express and Webpack. I've been checking some boilerplates to get up and running quickly, and I saw that you contribute to react-starter-kit, which seems like it could be a good choice!

[langpavel]

Hi, react-starter-kit is one of most popular and I think advanced ones out of there, but you should consider next.js if you don't feel with RSK.
Next.js can be more interesting for much larger community and easier to customize — especially if you will offer some kind of client

GraphQL is always best choice, I love postgres for backend but I'm not sure if you need relational store now, Redis will be great for key/value and pub-sub.

App should be easy to use, there should be an backing website and downloadable node.js client which can make accessible all the interesting files for the second party — this is always biggest problem — "A: Did you commit this? Which branch? B: I have some uncommitted changes on the master.."

Next big deal is with gitignored files.. Like node_modules, various configs.. For security reason they can be checked for presence, by hash and finally after given permission by content.

There should be some milestones:

1. Make website which let you find someone, for FOSS on GitHub there should be simple badge to follow
2. Offer cli tools which can help you sync and share, some master/slave mechanism known from DB replication can be used here
3. Online editing support without need to physical storage (client mode)

[sairamdevarashetty]

testing graphlql

[gustavlrsn]

@langpavel

Hi, react-starter-kit is one of most popular and I think advanced ones out of there, but you should consider next.js if you don't feel with RSK.
Next.js can be more interesting for much larger community and easier to customize — especially if you will offer some kind of client

I've been checking out Next.js, went through the tutorial and I really like it! It seems like a great choice, will probably go with this as it is much easier than having to deal with a complicated boilerplate and webpack configs etc.

GraphQL is always best choice, I love postgres for backend but I'm not sure if you need relational store now, Redis will be great for key/value and pub-sub.

A graphQL server connected to a postgres db seems like a good option.

App should be easy to use, there should be an backing website and downloadable node.js client which can make accessible all the interesting files for the second party — this is always biggest problem — "A: Did you commit this? Which branch? B: I have some uncommitted changes on the master.."

Downloadable node.js client? Could you elaborate? 🙂

Next big deal is with gitignored files.. Like node_modules, various configs.. For security reason they can be checked for presence, by hash and finally after given permission by content.

Are we talking about the process of pair programming here?

There should be some milestones:

Make website which let you find someone, for FOSS on GitHub there should be simple badge to follow
Offer cli tools which can help you sync and share, some master/slave mechanism known from DB replication can be used here
Online editing support without need to physical storage (client mode)

Badge is a good idea! CLI tools for pair programming?

Thanks again for your input!

[langpavel]

About cli I think tool which allows you share files from your filesystem subtree between coworkers.

[gustavlrsn]

Ah, I see! I think it would be outside the scope of this project right now, which is more about connecting people to pair program rather than building the tools for how to do it 🙂

[langpavel]

@gustavlrsn Ahh, I see :-) I'm coding completely remote so I think about this from different perspective :-)